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Abstract 

This  research  proposes  an  analytical  approach  to  access  the  relationship  between 
maintenance  facility  location  and  communication  network  performance  measurement  using 
a  selected  dynamic  maintenance  scheduling  protocol.  There  were  three  objectives 
established  for  this  effort  The  first  objective  was  the  determination  of  an  upper-bound 
upon  the  level  of  performance  for  a  telecommunication  network  using  dynamically 
scheduled  maintenance  to  evaluate  maintenance  depot  location.  This  was  achieved  by 
using  a  two-stage  algorithm,  first  locate  a  maintenance  depot  by  using  stochastic 
algorithms,  and  then  to  measure  the  resulting  impact  upon  performance  with  a  multi- 
commodity  network  flow  model.  The  second  objective  was  to  develop  the  metrics  by 
which  network  performance  should  be  measured.  This  was  accomplished  by  comparing 
multiple  criteria  using  a  constraint  conversion  technique.  The  third  objective  created  the 
mathematical  models  necessary  to  evaluate  network  operations.  The  models  were  created 
within  a  least-cost  multi-commodity  network  flow  environment.  The  approaches 
proposed  in  this  research  are  offered  as  initial  investigations  toward  the  long-term  goal  of 
automated  maintenance  scheduling  for  a  stochastic  communication  network. 


Dynamic  Maintenance  Scheduling 
for  a  Stochastic  Telecommunication 
Network:  Determination  of 
Performance  Factors 


I.  Introduction 

The  efficient  and  effective  allocation  of  maintenance  resources  to  support  today’s 
large-scale  telecommunications  networks  is  critical  if  the  highest  level  of  support  to  the 
users  of  these  networks  is  to  be  maintained.  This  chapter  first  provides  background  on 
telecommunications  networks  and  the  need  for  maintenance  scheduling.  Second,  this 
chapter  presents  the  thesis  research  objectives  with  a  description  of  the  scope  and  specific 
research  topics,  followed  by  basic  assumptions  about  the  telecommunications  network. 

1.1  Background 

Telecommunications  networks  have  experienced  tremendous  growth  in  the  last 
twenty  years.  This  is  particularly  true  for  Department  of  Defense  (DoD)  agencies,  where 
the  need  for  fast  reliable  communications  is  critical  to  decision  makers  and  operations 
personnel.  This  growth  has  made  these  communications  networks  extremely  complicated 
and  difficult  to  maintain.  While  there  has  been  a  tremendous  amount  of  research  into 
maximizing  the  flows  across  a  communications  network,  (which  increases  network 


1-1 


efficiency  and  throughput)  the  area  of  maintenance  scheduling  has  not  received  this  same 
level  of  attention. 

The  increases  in  network  complexity  dictate  the  reliance  upon  automated  control 
structures  for  minute-to-minute  operations  and  monitoring  of  a  communications  network. 
For  example,  the  physical  routing  of  a  call  and  call  loading  [defined  to  be  the  number  of 
calls  upon  any  link]  are  handled  via  automated  control  systems.  Maintenance  scheduling 
is  one  area  where  automated  controls  have  not  been  developed.  In  fact,  network 
custodians  currently  have  no  ability  to  assess  the  effect  of  the  maintenance  schedule  on 
network  performance. 

Maintenance  schedules  are  created  by  the  Telecommunications  Maintenance 
Office  (TMO),  which  schedules  three  types  of  maintenance  operations:  (1)  Corrective 
Maintenance  (CM),  which  includes  repair  of  equipment  after  it  has  failed  or  is  operating 
in  a  degraded  state;  (2)  Preventative  Maintenance  (PM),  which  is  routine  maintenance 
that  must  be  performed  on  the  network  to  prevent  failure  and  degradation  from  occurring; 
(3)  Adaptive  Maintenance  (AM),  which  includes  updates  to  network  equipment  or  even 
whole  new  systems  that  must  be  installed.  PM  and  AM  are  included  in  the  maintenance 
schedule,  while  the  first  type,  CM,  must  be  reactionary  and  thus  is  one  of  the  principal 
reasons  a  maintenance  schedule  must  be  changed.  Logically,  other  events  also  create  the 
need  to  change  maintenance  schedules.  For  example,  unavailability  of  replacement  parts 
and  unavailability  of  maintenance  personnel  (due  to  sickness,  improper  training,  etc.)  are 
only  two  of  many.  The  changes  that  occur  in  the  maintenance  schedule  will  then  affect 


1-2 


other  maintenance  tasks  depending  upon  their  priorities,  thus  creating  a  ripple  effect 
through  the  rest  of  the  schedule. 

TMO  persoimel  can  change  a  maintenance  schedule  by  hand.  However,  they  are 
currently  unable  to  assess  whether  they  are  creating  the  “best”  maintenance  schedule 
possible  since  the  TMO  currently  does  not  have  any  measures  of  network  performance  or 
models  upon  which  to  evaluate  performance  measures  if  some  were  chosen.  While  the 
TMO  has  several  Customer  Level  of  Support  Agreements  (LOSAs)  with  some  of  its 
customers,  the  TMO  managers  are  not  certain  that  these  LOSAs  provide  the  best  possible 
metric.  Additionally,  while  supporting  the  customers  is  of  primary  importance,  TMO 
managers  must  also  be  concerned  with  an  efficient  allocation  of  their  maintenance 
equipment  and  maintenance  personnel,  since  today’s  tumultuous  budgets  and  limited 
resources  could  create  a  situation  where  not  enough  maintenance  personnel  and 
equipment  are  available  to  meet  a  contingency  or  even  day-to-day  operations. 

The  limits  upon  maintenance  persoimel  and  equipment  also  play  a  role  in  the 
ability  of  the  TMO  to  meet  its  own  maintenance  schedules.  Personnel  can  become  sick  or 
injured  and  unable  to  perform  scheduled  maintenance  items  or  maintenance  equipment 
itself  can  break  with  the  same  result. 

All  of  these  factors  lead  to  the  concept  of  “dynamic  maintenance  scheduling”, 
which  is  defined  to  be  the  continuously  changing  process  of  scheduling  maintenance 
fimetions  for  telecommunications  operations.  While  on  the  surface  the  changes  in  the 
maintenance  schedule  appear  to  be  driven  by  CM  needs,  the  truth  is  that  each  type  of 
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maintenance  (along  with  the  limits  upon  maintenance  personnel  and  equipment)  affect 
this  constantly  changing  process. 

1.2  Research  Objectives 

1.2. 1  Scope  -  This  thesis  is  the  first  step  in  the  development  of  an  automated 
dynamic  maintenance  scheduling  system  for  the  Telecommunications  Maintenance 
Office  of  a  DoD  agency.  Specifically,  this  thesis: 

•  determines  an  upper-bound  upon  the  level  of  performance  for  a 
telecommunications  network  using  dynamically  scheduled  maintenance  to  evaluate 
maintenance  depot  location; 

•  develops  the  metrics  by  which  network  performance  should  be  measured;  and, 

•  creates  the  mathematical  models  necessary  for  network  evaluation. 

This  thesis  delivers  to  the  sponsoring  agency  three  things: 

•  a  set  of  insights  showing  the  effect  of  maintenance  depot  location  upon  network 
performance  and  maintenance  seheduling; 

•  a  model  formulation  for  measuring  network  performance  with  any  parametricly 
created  network  maintenance  schedule;  and, 

•  a  case  study  of  a  telecommunication  network  examining  various  network 
maintenance  schedules. 

This  thesis  does  not  develop  a  completely  automated  maintenance  scheduling  software 
package.  This  is  left  for  later  extensions. 


1-4 


1.2.2  Topics  -  The  scope  of  this  research  requires  focusing  upon  several  research 
topics:  network  reliability  and  availability  theory;  capacitated  multi-commodity 
networks  that  assume  stochastic  link  availability  and  demands;  and  automated  network 
solving  software. 

First,  network  reliability  and  availability  theory  will  be  used  to  help  determine  the 
metrics  for  evaluation  of  a  telecommimications  network.  Some  of  the  variables  that  are 
possible  candidates  in  the  formulation  and  modeling  process  include  system  reliability, 
degradation,  data  loss  rates,  data  delay  times,  call  throughput  rates,  and  availability  of 
service. 

Second,  capacitated  multi-commodity  network  theory  ’will  be  used  to  develop  the 
mathematical  models  of  network  operations  and  maintenance  fiinctions.  For  example, 
these  models  will  optimize  the  location  of  maintenance  depots  and  then  show  the  impact 
of  maintenance  depot  location  upon  network  performance.  Additionally,  the  model 
formulations  will  need  to  address  equity  issues  among  the  different  customers  since  each 
class  of  customer  will  need  to  receive  the  same  level  of  service  unless  otherwise  directed 
by  agency  managers. 

Finally,  the  working  computer  simulations  of  the  network  will  be  implementable 
upon  a  standard  network  solving  software,  such  as:  MICROSOL VE,  NETWORK- 
FLOW  SOLVER,  NETSIDE,  or  S AS/OR  [6]. 

1.3  Assumptions 
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The  basic  assumptions  that  carry  throughout  this  research  include: 

•  The  basic  network  is  a  multi-path  network  with  multiple  0-D  pairs  representing 
the  users  of  the  system; 

•  The  network  structure  has  a  circuit  switched  design  rather  than  packet¬ 
switching,  meaning  that  once  a  route  is  established  it  will  continue  with  allowance  for 
rerouting  as  necessary; 

•  The  flow  across  the  network  is  controlled  by  a  shortest  path  algorithm  that 
serves  as  the  message  routing  control  structure  and  as  a  congestion  control; 

•  Network  components  are  either  operational  or  failed  (a  component  requiring 
corrective  maintenance  action  can  be  considered  to  be  failed); 

•  Maintenance  operations  are  handled  on  a  first-come-first-serve  (FIFO)  basis; 

•  Maintenance  personnel  and  resources  do  the  “besf’ job  possible  in  performance 
of  their  tasks.  This  allows  for  direct  comparison  between  maintenance  operations  at 
competing  locations,  and  limits  the  research  area  to  location  and  performance  factors. 
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II.  Literature  Review 


This  chapter  reviews  topics  related  to  the  development  of  an  automated  dynamic 
maintenance  scheduling  system  for  a  telecommunications  network  including:  locating  the 
maintenance  facilities  supporting  a  network  operation,  performance  evaluation  models  of 
stochastic  networks,  and  the  principal  tenets  of  multiple-criteria  decision  making 
(MCDM).  First,  I  present  the  network  notation  and  symbols  to  be  used  throughout  this 
thesis.  Next,  I  cover  facility  location  literature  and  minimal-cost  network  flow  models,  to 
include  definitions  of  performance  metrics.  Finally,  I  provide  a  review  of  MCDM  topics 
and  their  possible  application  to  facility  location  and  network  performance. 

2. 1  Network  Model  Notation 

A  network  or  directed  graph  G  =  (N,A)  consists  of  the  distinct  node  set,  N  =  { 1 , 2, 

... ,  n}  and  the  set  of  m  distinct  arcs  (links),  A  ={(ij),  (k,l) . (s,t)}  represented  by 

directed  node  pair  combinations  going  from  node  i  to  node  j.  [2]  The  two  sets,  also  called 
network  components,  have  associated  numerical  values  representing  costs,  capacities, 
supply,  demand,  etc.  Specifically,  Cy  represents  the  arc  cost  associated  with  flow  from 
node  i  to  node  j,  while  arc  capacities,  Uy,  indicate  the  maximum  allowable  flow  upon  the 
arc.  Additionally,  an  external  flow  value  is  indicated  by  6,  which  has  a  positive,  negative, 
or  zero  value  if  the  node  is  a  source  ( supply),  sink  (demand),  or  intermediate  node  [25]. 
Additionally,  a  network  can  have  several  types  of  external  flow  representing  different 
commodities,  where  each  commodity  has  a  single  source  and  supply  node  [16]. 


2-1 


Obviously,  each  of  these  parameters  have  a  physical  interpretation  in  a 
telecommunications  network.  The  nodes  represent  banks  of  multiplexors  and  switching 
centers,  while  the  arcs  are  the  communications  links  between  these  centers  that  carry 
simultaneous  messages.  For  this  specific  problem,  each  node  is  a  separate  DoD  facility 
within  the  communications  network,  and  each  arc  is  the  communications  link  to  another 
facility  [18].  The  associated  arc  costs  can  be  an  number  of  things,  including:  Euclidean 
distances  (e.g.  miles);  units  of  time,  (e.g.  nano-seconds);  or  facility  usage  charges  (e.g. 
the  dollar  cost  to  use  a  dedicated  satellite-communication  link).  Arc  capacities  simply 
indicate  how  many  messages,  calls,  data  packets,  etc.  can  flow  simultaneously  over  a 
link.  The  external  flow  value  indicates  how  many  different  message  types  each  node 
either  sends  or  receives  from  another  node. 

The  representation  of  a  minimum  cost  network  flow  problem  as  a  mathematical 
program  has  an  objective  function  designed  to  minimize  the  cost  (time,  delay,  lost  calls, 
distance,  etc)  and  a  set  of  constraints  representing  the  feasible  region  [3].  The  constraints 
enforce  nodal  conservation  of  flow  and  arc  capacity  limits.  An  example  of  a  single 
commodity  unconstrained  minimum  cost  network  flow  model  is  Figure  2.1 : 

m  m 

Minimize 

/=!  7=1 

m  m 

Subject  to  =  bj  i  = 

j=l  k=l 

Xy>0  i,j  =  \,...,m 

where  Xy  =  message  flow  on  the  arc  between  node  i  and  j 
Figure  2.1  Unconstrained  Minimum  Cost  Flow  Model 
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2.2  Facility  Location  Models 

The  basic  goal  of  a  facility  location  problem  is  to  place  p  facilities  and/or  servers 
upon  a  network  to  provide  service  to  meet  a  set  of  demands.  The  service  in  this  case  will 
be  maintenance  operations  performed  at  each  communication  site  (node)  upon  a  link. 

There  has  been  a  tremendous  amount  of  research  into  the  area  of  facility  location 
by  members  of  the  public  and  private  sectors  [5].  Facility  location  models  can  generally 
be  divided  into  two  categories:  deterministic  and  stochastic.  The  system  to  be  modeled 
and  its  simplifying  assumptions  usually  determine  the  modeling  approach  to  use.  While 
deterministic  approaches  have  the  advantage  of  simplicity  and  ease  of  calculation, 
stochastic  models  sometimes  offer  a  better  representation  of  reality.  Both  types  will  be 
reviewed  below. 

2.2. 1  Deterministic  Models.  One  of  the  most  fundamental  of  deterministic  models 
developed  to  date  is  the  p-median  location  model  developed  by  Hakimi  [12]  in  1964  . 

The  p-median  approach  determines  optimal  facility  location  when  a  certain  set  of 
demands  must  be  met  by  minimizing  the  total  transportation  cost,  which  can  be  measured 
as  distance  or  time.  The  basic  model  developed  by  Hakimi  is 
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Minimize  YZfMj 

iel  jel 

Subject  To:  Vie/  (Service  Provided) 

jel 

=  p  (Number  of  Facilities) 
j£l 

Xjj  -  Xy  >  0  V/,y  €l,i  ^  j  (Facility  Servicing) 

Xy  >  0  (Non  -  negativity) 

Xjj  =  {1,0}  (Facility  Location) 
wrhere:  fj  =  frequency  of  maintenance  operation  (as  rate); 
djj  =  distance  to  node; 

Xjj  =  node  where  facility  is  located; 
p  =  number  of  facilities  to  be  located; 

I  =  set  of  nodes. 

Figure  2.2  P-Median  Location  Model 

This  simple  p-median  model  assumes  that  each  service  facility  handles  an 
exclusive  set  of  demands  with  no  overlap  between  service  facilities.  Chan  [5]  proposed  a 
relaxation  of  this  limit  by  allowing  the  different  service  regions  to  overlap.  In  his 
formulation,  a  node  could  belong  to  more  than  one  service  region,  thus  allowing  service 
to  be  provided  by  any  one  of  the  supporting  service  centers  depending  upon  the  state  of 
the  network.  An  important  assumption  of  both  the  simple  p-median  and  Chan 
formulations  is  disallowance  of  fractional  servicing  by  several  sites  (where  several  sites 
combine  efforts  to  work  on  the  affected  node).  This  assumption  is  driven  by  the  type  of 
service  to  be  performed,  for  instance,  service  calls  may  be  handled  by  an  individual 
person  and  would  therefore  be  impossible  to  split  out.  Obviously,  this  assumption  can  be 
relaxed  if  necessary. 
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Love  et  al.  [22]  proposed  another  deterministic  model  that  allows  for  interaction 
between  service  centers.  This  type  of  situation  can  occur  when  the  service  calls  are 
interrelated.  For  example,  traditional  telecommunication  maintenance  operations  are  set 
up  along  functional  lines  that  do  not  allow  for  overlap  and  each  site  will  only  have 
technicians  capable  of  dealing  with  certain  problems  [4].  When  a  service  call  arrives  it 
may  require  more  than  one  type  of  technician. 

The  solution  techniques  for  the  deterministic  models  discussed  vary.  When 
demands  are  paired  with  the  facilities,  the  simple  p-median  model  can  be  represented  as  a 
bipartite  graph  as  demonstrated  by  Chan  [5].  The  unique  structure  of  bipartite  graphs 
allows  them  to  be  solved  by  several  different  algorithms  including;  (1)  bipartite  preflow- 
push;  (2)  double  scaling  [2]. 

In  solving  the  overlapping  service  region  model,  Chan  [5]  proposes  using  a 
solution  dubbed  the  network-with-gains  algorithm  as  explained  in  his  book.  Chan  also 
experimented  with  simple  Mixed  Integer  Programming  (MIP)  and  the  node-arc- 
incidence-matrix  representation  using  side  constraints.  Chan  concludes,  “Of  the  three 
solution  procedures,  the  network-with-gains  algorithm  appears  to  be  the  most  promising.” 

[5] 

2.2.2  Stochastic  Models.  These  types  of  location  models  remove  some  of  the 
simplifying  assumptions  of  the  deterministic  p-median  models.  As  highlighted  by  Odoni 
[24]  in  1987,  arc  travel  times  will  vary  and  the  number  of  service  calls  waiting  to  be 
serviced  can  build  up  depending  upon  the  arrival  rate,  thus  creating  a  queuing  situation. 
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Obviously,  it  is  easier  to  deal  with  the  random  arc  travel  times  than  it  is  with  the 
second  relaxed  assumption.  Since  the  network  will  operate  over  a  long  period  and  can 
thus  be  assumed  to  have  reached  steady-state,  it  is  allowable  to  use  the  ‘average’  long-run 
travel  times  for  each  arc.  This  yields  the  same  results  as  the  p-median  approach.  The 
second  assumption  requires  use  of  stochastic  queuing  models.  Chan  points  out  that  these 
types  of  models  become  analytically  complex  when  the  number  of  facilities  goes  beyond 
one  facility  to  locate[5]. 

Ahituv  and  Berman  [1]  proposed  an  approach  for  modeling  this  situation 
involving  partitioning  a  network  down  into  smaller  subnetworks,  each  capable  of 
independent  operations.  Once  partitioned,  a  maintenance  facility  could  be  located  within 
the  new  subnetwork  using  a  stochastic  facility  location  algorithm  for  a  single  facility. 

2.2.2. 1  Network  Partitioning  Algorithm.  Garfinkel  and  Nemhauser  [9] 
created  an  elaborate  partitioning  algorithm  to  handle  political  redistricting.  This  work 
served  as  a  guide  only  until  Ahituv  and  Berman  [1]  were  able  to  adapt  the  model.  Their 
adaptation  considers  three  key  ideas  in  network  division: 

(1)  equity  (demand  for  maintenance  services  should  be  equal  across  the  larger  network); 

(2)  contiguity  (each  node  of  the  subnetwork  can  be  reached  without  having  to  pass 
through  a  node  assigned  to  another  subnetwork);  and, 

(3)  compactness  (the  distance  between  nodes  of  any  subnetwork  is  constrained).  Their 
adaptation  of  the  model  takes  the  form  shown  in  Figure  2.3. 
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The  purpose  of  constraint  (1)  is  to  ensure  the  required  number  of  subnetworks. 

The  second  constraint  (2)  fulfills  the  collectively  exhaustive  and  mutually  exclusive 
requirements. 

The  real  problem  with  this  model  lies  in  the  fact  that  it  is  an  exhaustive 
enumeration  technique  that  requires  a  large  number  of  constraints  to  implement.  For  a 
simple  network  of  only  five  nodes,  this  formulation  creates  120  possible  network 
partitions  to  evaluate.  Since  most  communications  networks  have  several  hundred  to 
thousands  of  nodes  this  technique  requires  a  large  amount  of  computer  time  to  operate. 

MinlQ  Xj 
j=i,s 

Subject  To:  ZXj  =  M  (1) 

j=i,s 

ZaijXj  =  l  i=l . n  (2) 

j=i,s 

where:  Xj  =  1  if  subnetwork  j  is  selected 
=  0  otherwise; 

aij  =  1  if  node  i  is  an  element  of  subnetwork  j 
=  0  otherwise; 

M  =  number  of  subnetworks; 

n  =  number  of  nodes; 

IXhi-l/Ml 

Cj  =  a/M  Zisoveri  €  j;0<a<l 

hi  =  node  i  fraction  of  demand. 

Figure  2.3  Network  Partitioning  Model 


Kumar  and  Babu  [20]  developed  another  partitioning  technique  for 
communications  networks  using  a  stochastic  search  method  called  evolutionary 
programming  to  search  for  a  globally  optimal  partition  based  upon  minimization  of 
communications  cost.  Evolutionary  programming  techniques  mimic  the  fundamental 


2-7 


aspects  of  evolution  and  have  been  shown  to  converge  asymptotically  to  the  global 
optimum  [20]. 


2. 2. 2. 2  Stochastic  Location  Algorithm.  Once  a  network  is  partitioned  into 
p  subnetworks,  each  subnetwork  needs  to  have  a  maintenance  facility  placed  vvdthin  the 
confines  of  the  subnetwork.  The  development  of  the  stochastic  location  algorithm  comes 
from  [1,5]:  MinTRj(X)  V  jel 

where  the  minimum  TRj  is  computed  by  taking  the  first  derivative  for  each  possible 
location]  within  the  set  I.  The  expected  response  time  (TR)  is  the  sum  of  the  mean- 
queuing-delay  {Q)  and  the  mean  travel  time(  t ),  highlighted  as: 

TR{X)  =  Q+i 
Q  is  further  defined  as: 

^  2(1-A5(JT)) 

X  is  the  facility  location,  X  is  the  failure  arrival  rate,  S(X)  is  the  mean  total  service  time 
(first  moment  of  service  time),  and  S^(X)  is  the  second  moment  of  the  total  service  times. 

This  formulation  is  easy  to  solve  provided  the  maintenance  depot  is  placed  at  a 
node  in  the  communications  network.  This  assumption  is  a  reasonable  given  the 
assumption  maintenance  operations  occur  at  the  nodes  and  additionally,  in  all  likelihood 
the  network  managers  would  want  the  facilities  to  be  co-located  [18]. 

2. 3  Minimum  Cost  Network  Flow  Models 

2.3.1  Basic  Formulation.  A  multicommodity  minimal  cost  flow  (MMCF) 
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problem,  as  explained  by  [16]  in  1978,  attempts  to  determine  the  minimal  cost  flow  of 
multiple  commodities  through  a  network  subject  to  (1)  supply  and  demand  requirements, 
(2)  arc  capacity  limits,  and  (3)  flow  conservation  at  transshipment  nodes.  The 
mathematical  representation  of  a  MMCF  can  have  a  node-arc  formulation  or  an  arc-path 
formulation.  The  node-arc  formulation  is: 

p^qeD 

Subject  To: 

Capacity:  VueM 

p&OqeD 

Flow  Conservation:  ^  ^  ,  if  i  =  p 

uer{i)  uer-(i) 

Mer(o  M€r~*(/) 

^  X^'^  -  ^  X^*'  =  0  otherwise 
Mer(/)  Mer-(0 

Non  Negativity:  X^‘'  >0  V  u  gM,  p  eO,  q  gD 

where  X^**  Traffic  flow  of  O  -  D  (p  =  origin  & 

q  =  destination  using  arc  u); 
u„  Capacity  of  arc  u; 
d  Origin  -  destination  offered  load; 

r(z)  Set  of  arcs  whose  origin  node  is  i; 
r  -  (0  Set  of  arcs  whose  terminal  node  is  i; 

O  Origin  node  set; 

D  Destination  node  set; 

N  Node  set  for  network; 

M  Arc  (link)  set  for  network. 

Figure  2.4  Node-Arc  Formulation  of  Network  Flow  Model 
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The  formulation  of  the  arc-path  model  will  not  be  presented  since  the  node-arc 
model  forms  the  basis  of  the  performance  evaluation  model  described  in  the  next  chapter. 

This  multicommodity  minimum  cost  model  considers  only  a  single  time  period, 
or  the  system  it  represents  can  be  considered  to  be  at  steady  state.  This  poses  a  problem 
for  network  maintenance  schedulers  when  attempting  to  use  this  type  of  a  model  to 
determine  the  impact  upon  network  performance  of  a  dynamic  maintenance  schedule.  In 
a  soon  to  be  published  paper,  Haghani  and  Oh  [1 1]  have  developed  a  dynamic  network 
flow  model  representing  multiple  time  periods  as  well.  Their  work  focused  on 
minimizing  the  vehicular,  commodity,  supply/demand,  and  transfer  costs  for  a 
transportation  network.  Their  work  is  useful  in  realizing  the  necessary  structure  for 
dynamic  network  model  that  considers  many  time  periods.  The  obvious  problem  with 
such  a  model  is  the  linear  system  of  equations  created  would  be  tremendously  large,  and 
the  advantage  of  special  network  structures  would  probably  break  down. 

2. 3. 2  Network  Routing.  Routing  protocols  perform  the  job  of  determining  the 
“best”  possible  path  through  a  network  for  each  0-D  pair  [15].  There  are  two  primary 
routing  algorithms  in  use  today:  shortest  path  and  delay.  Shortest  path  algorithms,  also 
called  distance-vector  algorithms,  can  be  based  upon  physical  distances  or  the  number  of 
“hops”  [15].  The  goal  of  this  protocol  is  to  minimize  the  number  of  “hops”  between 
source  to  sink,  where  a  “hop”  is  defined  as  passage  through  an  intermediate  node. 

The  second  protocol,  delay,  is  simply  the  amoimt  of  time  that  it  takes  a  message  to 
reach  its  destination  from  its  origin  [15].  At  first  inspection,  this  could  be  considered  as 
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the  shortest  path,  but  this  is  not  the  case.  The  amount  of  time  it  takes  a  message  to  go 
from  source  to  sink  is  also  influenced  by  congestion  effects  upon  each  link  [23:278].  Li 
and  Silvester  [21]  present  simple  techniques  for  estimating  the  impact  on  network 
performance  using  Kleinrock’s  average  network  delay  formula  [17]: 


Delay  =  — ^ 


Kj 


where:  7  is  total  network  throughput; 

1  /  jU  is  average  message  length; 

Aj j  is  flow  upon  link  i,  j 

This  delay  function  can  then  be  used  to  minimize  average  network  delay  through  each 
link  and  hence  the  “best”  path  is  achieved  for  each  message  based  upon  network 
congestion. 


2.3.3  Solution  Algorithms.  Multicommodity  network  flow  problems  are  linear 
programs  and  could  thus  be  solved  using  the  simplex  method,  but  large  networks  can  lead 
to  extremely  large  problems.  Network  solution  algorithms  are  designed  to  take  advantage 
of  special  structures  [3:419, 16:219].  The  choice  of  network  solution  algorithms  for 
capacitated  multicommodity  network  flow  problems  is  affected  by  the  special  structure  of 
the  problem.  Unlike  a  single  commodity  problem,  the  multicommodity  problem  has  an 
additional  set  of  constraints  (side  constraints)  that  make  the  solution  algorithm  more 
complicated. 

Kennington  states  there  are  three  basic  approaches  for  solution:  (1)  price- 
directive  decomposition;  (2)  resource-directive  decomposition;  and,  (3)  partitioning 
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methods  [16].  One  solution  algorithm  that  uses  the  first  decomposition  technique  is  the 
specialized  Dantzig-Wolfe  decomposition  algorithm  [3:320-349, 16:221].  Readers 
interested  in  more  solution  algorithms  for  multicommodity  flow  problems  can  turn  to 
Kennington’s  authoritative  review  [16]  presented  in  1978. 

2.4  Multiple  Criteria  Decision  Making 

In  the  last  few  decades  there  has  been  a  realization  within  the  operations  research 
commimity  that  in  most  situations  there  are  several  criteria  that  usually  need  to  be 
examined  and  compared  in  order  to  determine  the  “best”  solution  to  a  problem  [30, 10, 
19].  Quite  often  these  criteria  must  be  compared  against  each  other  in  some  fashion  that 
usually  involves  a  compromise  between  each  criteria’s  “ideal”  value  in  order  to  find  a  set 
of  nondominated  alternatives. 

The  mathematical  expression  of  a  p-dimensional  multi-criteria  problem  has  the 
form  [10]: 

Max  z(x)  =  [z,  (x),  z^{x),...,Zp\ 

Subject  To:  gi(x)  <  0  i  =  l,...,m 
Xj  >0  j  =  l,...,n 

where  gi(x)  is  the  feasible  region  -with  the  goal  of  this  formulation  being  to  find  the  set  of 
non-dominated  solutions.  The  non-dominated  solution  set  can  then  be  used  to  determine 
the  Pareto  (more  is  better)  optimal  based  upon  a  known  or  revealed  preference  structure 
[8:8,  28:14]. 
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The  network  flow  model  I  develop  in  the  next  chapter  is  an  example  of  a 
multicriteria  decision.  This  model  must  balance  a  network  relaibility  measure  against 
network  availability  and  flow  routing. 

2.4.1  User  Vs.  Operator  Trade-offs.  The  above  formulation  for  multi-criteria 
decisions  describes  possible  trade-offs  within  a  model,  but  there  is  another  aspect  to  this 
type  of  decision  making.  Quite  often  the  decision  maker  must  make  comparisons 
between  two  different  models.  For  example,  the  locating  of  a  maintenance  facility  using 
the  minimum-time-to-respond  to  a  service  call  as  the  performance  metric  is  an  operator’s 
perspective  while  the  network  flow  model  measuring  network  performance  is  a  measure 
of  a  network  user’s  perspective. 

Clearly,  the  two  perspectives  come  into  conflict  if  a  solution  for  one  results  in  a 
sub-optimal  solution  for  the  other.  Idealy,  I  would  like  to  have  a  win-vdn  situation  where 
both  models  reach  maximum  “happiness”.  As  Manheim  indicates,  this  is  not  always 
possible  since  the  optimal  maintenance  facility  location  for  a  system  operator  might  not 
result  in  optimal  network  performance  from  a  system  user’s  perspective  [23:191].  If  a 
win-win  situation  does  not  exist  then  I  am  faced  with  another  multicriteria  decision 
problem  to  compare  the  two  models. 

2.4.2  Solution  Approaches.  Ross  and  Soland  [26]  discuss  several  different 
solution  approaches  to  find  the  Pareto  optimal  for  deterministic,  multi-criteria  problems: 
value  ftinctions,  efficient  solution  sets  (frontiers),  and  interactive  algorithms.  Using  the 
notation  introduced  in  Chan  [7],  let  Y  be  the  outcome  space,  where  y  =  f(x)  represents  the 
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vector  of p  criterion  functions  discussed  previously,  and  y*  is  the  outcome  of  alternative 

1. 

2.4.2. 1  Value  Functions.  Value  functions  assume  the  analyst  has  some 
prior  knowledge  of  the  decision  maker’s  imderlying  preference  structure  [25].  The  value 
function  v(y)  is  defined  such  that  y  >-  y  ,  if  and  only  if  v(y  )  v(y  )  [5].  The  obvious 
difficulty  with  this  approach  is  in  determining  the  value  function  v.  This  value  function 
for  the  performance  model  is  definitely  unknown  at  this  time  since  the  sponsor  is  still 
trying  to  decide  upon  what  is  important  to  measure. 

2. 4. 2. 2  Interactive  Algorithms.  The  interactive  algorithm  method  requires 
the  analyst  and  decision  maker  to  work  together  as  the  solution  space  is  refined  and 
broken  out,  incorporating  the  decision  maker’s  preferences  as  each  step  is  accomplished. 
According  to  Ross  and  Soland  [26]  this  solution  method  can  lead  to  the  selection  of  a 
non-efficient  solution. 

2. 4. 2. 3  Efficient  Frontier.  The  efficient  frontier  is  the  set  of  efficient 
solutions.  This  approach  relies  upon  generating  the  set  of  solutions  that  the  decision 
maker  should  consider  [10]. 

Goicoechea  describes  four  methods  to  arrive  at  an  efficient  frontier:  (1)  weighting 
method;  (2)  constraint  method;  (3)  Phillip’s  linear  multiobjective  method;  (4)Zeleny’s 
linear  multiobjective  method  [10].  Hsu  and  Tseng  [14]  have  developed  a  new  method 
combining  the  first  two  methods,  called  the  CONWEIGHT  algorithm.  While  this  method 
is  intriguing,  I  will  use  the  constraint  method  in  the  next  chapter  to  generate  the  non- 
dominated  set  for  the  performance  evaluation  model. 
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IIL  Model  Formulation 


This  chapter  descrihes  the  mathematical  models  and  approaches  used  to  model  the 
communication  network.  First,  we  present  a  problem  summary  and  research  objectives 
that  the  models  are  designed  to  achieve.  The  next  two  sections  discuss  the  two  major 
optimization  perspectives  and  the  development  of  the  network  partitioning,  facility 
location,  and  performance  measurement  models.  The  last  section  presents  the  complete 
solution  algorithm  incorporating  the  models  used  as  a  solution  procedure  and  the  software 
packages  used  for  solution. 

3.1  Problem  Summary 

The  long-term  research  problem  has  an  ultimate  goal  of  automating  the  scheduling 
process  of  a  telecommunication  network  while  seeking  to  utilize  the  maintenance 
resources  as  efficiently  as  possible  and  at  the  same  time  provide  the  highest  level  of  service 
possible  to  the  customer.  The  writing  of  a  simple  computer  program  to  do  automated 
scheduling  would  be  fairly  simple,  but  it  would  not  necessarily  guarantee  the  “best” 
possible  solution,  particularly  when  we  are  not  yet  even  sure  of  the  criteria  that  should  be 
used  in  determining  “best”  or  even  how  to  compare  them.  Hence,  this  specific  thesis 
research  goal  is  the  development  of  models  to  evaluate  the  impact  of  changes  in  the 
dynamic  maintenance  schedule  of  a  telecommunication  network  upon  selected  network 
performance  measures.  This  statement  creates  several  questions  that  must  be  addressed 
before  each  of  the  research  objectives  can  be  accomplished:  (1)  What  performance 
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measures  need  to  be  considered?  (2)  Should  the  system  be  optimized  from  the  operator 
perspective  or  from  the  user  perspective,  or  does  it  even  matter? 

How  each  of  these  questions  is  answered  in  the  next  few  sections  determines  how 
each  of  the  three  research  objectives  are  met.  Recall  that  the  research  objectives  are: 

•  determine  an  upper-bound  upon  the  level  of  performance  for  a 
telecommunications  network  by  optimal  basing  of  maintenance  facilities  using  dynamically 
scheduled  maintenance; 

•  develop  the  metrics  by  which  network  performance  should  be  measured;  and, 

•  create  the  mathematical  models  necessary  for  network  evaluation. 

3.2  Operator  Vs.  User  Perspective 

The  first  issue  of  maintenance  schedule  optimization  that  must  be  addressed  before 
proceeding  into  model  development  is  system  optimization  perspective.  The  classical 
approach  is  to  optimize  a  system  from  either  the  user  perspective  or  the  operator 
perspective  [23: 198].  Quite  often  the  results  achieved  from  the  user  perspective  will  be 
quite  different  than  those  yielded  by  the  operator  perspective.  For  example,  the  classic 
Braes  Paradox  transportation  network  solution  yields  two  different  optimal  solutions, 
depending  upon  which  perspective  is  used  as  the  basis  for  optimization. 

I  decided  to  approach  the  research  problem  sequentially  using  results  of  operator 
optimization  in  creating  the  results  for  the  user  optimization.  The  goal  of  this  approach  is 
to  demonstrate  the  affect  maintenance  depot  location  has  upon  network  performance 
when  both  perspectives  are  incorporated  into  maintenance  scheduling  operations. 
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The  modeling  approach  used  for  this  type  of  formulation  requires  breaking  the 
problem  down  into  a  model  to  optimize  operator  performance  and  one  to  optimize  user 
performance.  These  models  are  then  run  sequentially  to  develop  an  algorithm  for  the 
complete  picture. 

3.3  Performance  Models 

Before  discussing  the  two  models,  it  is  important  to  state  specific 
assumptions  used  in  both  perspectives: 

(1)  Network  communication  links  (arcs)  are  either  up  (operational)  or  down  for 
maintenance  (broadly  referred  to  as  failed).  While  the  links  fail,  the  actual  maintenance 
activities  occur  at  a  node.  It  is  important  to  realize  that  I  am  attempting  to  model  network 
maintenance  procedures  and  the  effect  these  procedures  have  upon  network  operations, 
not  just  straight  data  or  message  flow  within  any  generic  telecommunications  system.  I 
think  it  is  important  to  take  a  moment  and  explain  this  further. 

Each  link  (arc)  between  two  sites  (nodes)  within  a  telecommunication  network 
usually  contains  many  individual  lines.  My  observation  of  the  sponsor’s  outage  reports  for 
its  telecommunication  network  indicate  outages  are  constantly  occurring  on  individual 
lines  between  two  sites,  yet  the  link  continues  to  operate  in  a  degraded  state.  According 
to  the  sponsor  these  outages  do  not  always  need  maintenance  personnel  to  take  any 
action.  The  outages  could  be  due  to  weather,  sun-spot  activity,  or  many  other 
phenomenon  that  eventually  clear  themselves.  [18]  At  this  time,  attempting  to  model  each 
link’s  operations  in  a  degraded  state  would  be  extremely  difficult  and  unnecessary  since  I 
am  interested  in  the  effect  maintenance  has  upon  the  network. 
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There  are  three  types  of  network  maintenance:  Adaptive  (AM),  Preventative 
(PM),  and  Corrective  (CM).  The  reliability  value,  ajj ,  attached  to  each  link  in  the  model 

represents  the  proportion  of  time  over  the  long  run  that  the  link  is  operational  and,  1-a,  is 
the  proportion  of  time  the  link  is  down  for  all  three  types  of  maintenance.  This  approach 
will  also  necessitate  a  solution  technique  using  networks  with  gains.  Hence  this  approach 
does  not  make  a  distinction  between  the  types  of  maintenance.  It  only  assumes  that 
maintenance  occurs  and  that  any  type  of  maintenance  activity  would  take  the  link  down 
for  some  variable  period  of  time.  The  bi-modal  assumption  allows  me  to  model  the  effect 
of  maintenance  operations  upon  network  performance.  An  advantage  of  using  network 
reliability  rates  is  the  elimination  of  the  need  to  solve  the  network  many  times  sequentially 
to  simulate  multiple  time  periods. 

(2)  Failure  rates  (the  rate  at  which  calls  are  made  on  the  service  organization)  will  be 
modeled  according  to  a  Poisson  process.  [1:64] 

(3)  The  servicing  organization  must  handle  all  network  failures  (maintenance  calls)  since 
it  is  the  only  entity  that  repairs  inoperative  nodes.  Hence,  we  are  modeling  an  infinite 
capacity  queue.  This  is  a  logical  assumption  since  if  the  network  is  not  repaired  customer 
service  levels  would  not  be  maintained. 

(4)  The  network  structure  assumes  continuous  24-hour  operations.  It  is  also  assumed  to 
be  at  steady  state. 

(5)  The  server  must  always  return  to  the  service  depot  node  after  completing  a  job  and 
before  starting  on  a  new  job.  [1:64] 
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(6)  Each  service  (maintenance)  call  is  handled  in  a  first-in-first-out  (FIFO)  queue 
discipline. 

(7)  We  must  assume  that  the  time  required  to  complete  a  repair  job  is  stochastic  in  nature, 
since  some  breakdowns  are  worse  than  others.  There  are  four  factors  forming  the 
maintenance  process  for  each  job: 

(1)  Travel  time  from  the  depot  node  to  the  failed  node 
(Deterministic). 

(2)  Time  required  to  repair  the  facility  (Normally  distributed). 

(3)  Return  time  to  depot  node  (Deterministic). 

(4)  Regeneration  time  in  preparation  for  next  service  call. 

(Normally  distributed).  [1:64] 

(8)  The  nodes  are  assumed  to  be  100%  reliable.  [18]  Nodes  subject  to  failure  could  me 
modeled  by  representing  the  site  as  two  nodes  connected  by  a  dummy  arc. 

(9)  The  length  of  a  message  carried  on  the  network  is  constant  or  deterministic. 

Using  the  previous  assumptions,  it  is  possible  to  model  this  servicing  facility  as  a 
queuing  system  of  the  form  M  /  G  / 1  /  “,  where  M  indicates  that  the  failures  arrive 
according  to  a  Poisson  process,  G  indicates  there  is  a  general  distribution  of  service  times, 
1  indicates  a  single  server,  and  “  indicates  a  queue  with  infinite  capacity.  [1:64] 

3.3.1  Operator  Performance  Model.  The  operator  perspective  performance 
model  was  developed  around  the  goal  of  optimizing  maintenance  depot  locations 
supporting  the  telecommunication  network.  The  previous  chapter  presented  the  two  types 
of  facility  location  models  and  solution  techniques  (stochastic  and  deterministic)  that  have 
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been  developed.  I  chose  the  stochastic  modeling  approach  from  that  discussion  which 
necessitates  breaking  the  location  model  down  into  a  partitioning  model  and  then  a 
subnetwork  location  model. 

The  performance  measure  chosen  to  be  optimized  was  minimum  time-to-respond 
(TR)  to  a  maintenance  call  from  a  centralized  maintenance  depot.  My  reasons  for  using 
this  metric  include;  there  has  been  some  amount  of  research  into  this  subject  by  Ahituv 
and  Berman  [1]  and  follow-on  work  performed  by  Chan  [5];  additionally,  the  total 
expected  response  time  does  encompass  some  of  the  criterion  currently  used  in  the 
LOS  As:  reliability  and  availability;  in  that  the  faster  a  problem  (failure  or  other 
maintenance  operation)  within  the  network  is  fixed,  the  higher  the  network’s  reliability  and 
availability  of  service  should  be. 

3. 3. 1.1.  Network  Partitioning  Algorithm.  As  stated  in  the  previous 
chapter,  the  partitioning  model  considers  three  principal  factors:  equity,  contiguity,  and 
compactness.  The  detailed  explanation  for  each  factor  is  presented  next. 

Equity  as  defined  by  Ahituv  and  Berman,  “...the  concept  of  equity  asserts  that  the 
entire  population  of  potential  clients  [each  node  of  the  communications  network]  be 
treated  as  equally  as  possible  in  terms  of  the  quality  of  service  they  get.  In  other  words, 
subpopulations  of  customers  shall  not  be  deprived  by  the  service  provider.”  [1:24]  This 
appears  to  be  a  logical  and  necessary  standard  since  the  maintenance  office  as  the  provider 
of  the  service  (maintenance)  should  not  be  the  determiner  of  who  gets  service.  He  must 
ensure  that  everyone  gets  equal  service  unless  directed  to  do  otherwise  by  superiors. 
Obviously,  there  can  be  different  classes  of  customers  to  be  considered  since  national 
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decision  makers  will  have  a  higher  priority  for  maintenance  service  than  will  an 
administrative  support  user  during  a  time  of  national  crisis,  but  this  can  be  included  as  a 
weighting  factor.  These  priorities  would  still  be  set  by  the  decision  makers  and  system 
users,  not  by  system  operators. 

The  quantitative  formulation  of  equity  comes  from  [1:26]: 

M  =  desired  number  of  subnetworks; 

/i  =  1  /  M;  if  each  subnetwork  obtains  exactly  h  fraction  of  maintenance 
service,  we  would  have  perfect  equity.  Since  it  is  not  always  feasible  to  have  perfect 
equity,  there  must  be  a  margin  on  either  side  (called  a)  that  is  acceptable  (ie,  10%). 
Overall,  a  proposed  subnetwork,  G, ,  is  feasible  if 
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There  are  two  other  principle  that  I  will  include  in  the  model:  contiguity  (T)  and 
compactness  (P).  Contiguity  for  our  purpose  is  the  ability  to  travel  from  each  node  in  the 
subnetwork  to  every  other  node  within  the  subnetwork  without  having  to  use  links  of  a 
different  subnetwork.  You  may  cross  another  network,  but  you  can  not  use  its  links. 
Compactness  means  simply  that  we  want  the  nodes  of  our  subnetworks  to  be  close 
together  and  not  spread  out.  This  is  accomplished  by  simply  including  a  maximum 
distance  constraint  upon  the  subnetwork.  [1 :26-8] 

The  actual  model  I  will  use  is  based  upon  the  work  of  Garfinkel  and  Nemhauser, 
whose  algorithm  was  developed  for  use  primarily  in  political  rezoning  and  district 
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structuring.  Their  model  is  based  upon  enumeration  and  was  adapted  for  network 
topology  by  Ahivut  and  Berman  [1]: 


Min  XCjXj 

j=hS 

Subject  To:  ^Xj=M  (1) 

j=hS 

^a.jXj=l  i  =  (2) 

j=is 

where:  Xj  =  1  if  subnetwork  j  is  selected; 

=  0  otherwise; 

tti  j  =  1  if  node  i  is  an  element  of  subnetwork  j; 
=  0  otherwise; 

M  =  number  of  subnetworks; 
n  =  number  of  nodes; 


'Lih-y« 

isj 


0  <  a  <  1,  hi  =  fraction  of  demand  at  node  i 


Figure  3. 1  Network  Partitioning  Model 


The  purpose  of  constraint  (1)  is  to  ensure  that  we  get  the  required  number  of 
subnetworks.  Constraint  (2)  fulfills  the  collectively  exhaustive  and  mutually  exclusive 
requirements. 

The  algorithm  consists  of  two  different  phases:  Phase  I  determines  all  feasible 
subnetworks  within  the  larger  network,  and  Phase  II  determines  the  final  subnetworks 
based  upon  our  equity  objective  function.  Contiguity  and  compactness  will  be  bounding 
constraints  for  the  first  phase.  One  final  requirement  is  that  the  M  subnetworks  must  be 
collectively  exhaustive  and  mutually  exclusive.  In  other  words,  every  node  must  be  within 
one  and  only  one  subnetwork.  This  is  accounted  for  in  Phase  II.  [1:34] 
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PHASE  I:  [1:34]  Using  a  “tree  search”  algorithm  we  find  the  feasible  set  by 
picking  the  smallest  number  node  and  connecting  contiguous  nodes  while  enforcing  the 
compactness  requirement  until  the  combined  demand  becomes.  Attention  must  be  paid  to 
not  creating  separate  enclaves,  which  are  node(s)  that  are  incapable  of  being  separate 
subnetworks  and  can  not  be  connected  to  other  subnetworks  without  going  through  a 
previously  defined  subnetwork.  This  will  prevent  impossible  solutions. 

PHASE  II:  [1:38-41]  The  algorithm  for  node  partitioning  was  developed  by 
Garfinkel  and  Nemhauser  in  1970.  The  following  notation  is  needed: 

D  is  the  set  of  fixed  variables; 

N(D)  is  the  number  of  fixed  variables; 

U  is  the  set  of  nodes  in  zones  of  D; 

Y  is  the  set  of  zones  in  the  current  partial  solution; 

T  are  the  nodes  in  the  zones  of  Y. 

The  steps  are  briefly  outlined  below: 

Step  1:  Initialization.  Set  L=0,  Y=D,  T=U 

Step  2:  Choose  next  list.  Pick  the  smallest  numbered  node  not  in  T 

Step  3:  Adding  a  zone  to  Y. 

Step  4:  Backtracking.  If  L=0  stop,  else  L=L-1 
Step  5:  Test  for  a  solution.  Test  L  =  M  -  N(D) 

Step  6;  Solution  is  found.  Largest  cost  of  district  in  Y. 

My  final  goal  was  to  automate  the  entire  process  into  a  spreadsheet.  This  would 
have  the  effect  of  allowing  the  user  to  enter  a  model  and  then  break  it  into  as  many  pieces 
as  desired,  but  I  was  unable  to  automate  the  first  phase  which  included  the  contiguity  and 
compactness  constraints.  My  problem  with  Phase  I  was  that  I  could  not  form  an  approach 
for  the  tree  search  algorithm  using  the  spreadsheet.  This  will  be  left  for  a  later  extension. 

I  think  that  the  Phase  I  can  eventually  be  converted  to  some  sort  of  linear  programming 
model  similar  to  the  Phase  n  model,  which  I  was  able  to  implement  in  a  spreadsheet. 
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3. 3. 1.2.  Facility  Location  Algorithm.  The  next  step  is  to  determine  where 
the  maintenance  depot  should  be  placed  within  the  network.  The  optimal  location  is 
determined  using  the  minimized  expected  response  time  for  a  maintenance  call.  The 
development  of  the  stochastic  location  algorithm  comes  from  [5, 1]: 

Min  TRj(X)  V  j  e  I 

where  the  expected  response  time  (TR)  is  the  sum  of  the  mean-queuing-delay 
(  Q  )  and  the  mean  travel  time(  t ),  highlighted  as: 

TR{X)  =  Q+t 
Q  is  further  defined  as: 

y^s\x) 

^  2{\-XS{X)) 

X  is  the  facility  location,  L  is  the  failure  arrival  rate,  S(X)  is  the  mean  total  service  time 

(first  moment  of  service  time),  S^(X)  is  the  second  moment  of  the  total  service  times. 

This  formulation  is  easy  to  solve  provided  the  maintenance  depot  is  placed  at  a 

node  in  the  communications  network.  This  assumption  is  reasonable  given  I  am  using  the 

assumption  that  maintenance  operations  occur  at  the  nodes  and,  additionally,  the  network 

managers  would  probably  want  the  facilities  to  be  co-located  [18]. 

Chan  [5]  presents  a  very  important  observation  about  this  formulation:  the  time  to 

repair  a  facility  and  the  regeneration  time  before  a  next  call  are  zero.  This  assumption  can 

be  made  since  this  amount  of  time  will  be  treated  as  a  constant  when  the  objective  function 

for  TR  is  minimized  by  taking  its  first  derivative,  and  it  will  thus  be  eliminated.  The 

objective  function  is  defined  as:  I 

F(X)=  Ihjd(X,j) 

j=l 
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where  I  is  the  total  number  of  nodes,  hj  is  the  demand  proportion  at  each  node,  and 

d(X,j)  is  the  shortest  distance  between  X  and  node  j. 

3.3. 1.3  Model  Significance.  The  two  previous  algorithms  are  used 
sequentially  to  form  a  model  determining  optimal  facility  location  from  the  network 
operator  perspective.  The  result  of  this  model  is  the  creation  of  an  outage  record  and 
more  importantly  a  dynamic  maintenance  schedule  that  is  then  used  to  drive  the  network 
performance  model  evaluating  user  perspective. 

3.3.2  User  Performance  Model.  The  mathematical  representation  of  the  model  as 
adapted  from  Sanso,  et  al.  is  shown  in  Figure  3.2  [27].  My  extensions  to  this  model 
include:  the  third  objective  function  for  average  link  delay;  and,  the  inclusion  of  link 
availability  rates  to  represent  maintenance  scheduling. 
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(Number  of  Lost  Calls) 


MinZl  =  II 

peOqeD 

Min  Z2  =  ^  ^  ^  Xf  (Shortest  Path) 

ueM  peOqeD 

MinZ3  = 

ueM 

peOqeD 

Subject  To: 

Capacity:  II  Xf  <  C„  V  u  e  M 

peOqeD 

Flow  Conservation:  -  7^^ ,  if  i  =  p 

«er(i)  «sr-(i) 

Ia.X«-  Xa.X«=-<i«+y",ifi  =  q 

ueTU)  ubF-U) 

=0  otherwise 

Mer(/)  ugr-(i) 

Non  Negativity:  X” ,  YP'*  >  0  V  u  e  M,  p  e  O,  q  g  D 

where  X”  Traffic  flow  of  O  -  D  (p  =  origin  &  q  =  destination  using  arc  u); 
Cu  Capacity  of  arc  u; 

Origin  -  destination  offered  load; 

Origin  -  destination  lost  traffic; 
r(i)  Set  of  arcs  whose  origin  node  is  i; 
r  -  (0  Set  of  arcs  whose  terminal  node  is  i; 
a^  Availability  rate  of  link  as  a  proportion; 
w  ^  Weighting  priority  given  to  the  p  -  q  commodity ; 
lu  Length  of  arc  between  nodes; 

O  Origin  node  set; 

D  Destination  node  set; 

N  Node  set  for  network; 

M  Arc  (link)  set  for  network. 

Figure  3.2:  User  Performance  Model 
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(Data  Delay) 
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As  the  reader  can  see,  this  model  has  three  separate  objective  functions  (criterion) 
to  evaluate,  but  this  is  not  all  that  unusual.  These  criteria  must  be  compared  against  each 
other  in  some  fashion  that  usually  involves  a  compromise  between  each  criteria’s  “ideal” 
value.  The  last  two  objective  functions  are  where  the  many  potential  trade-offs  would 
have  to  occur  since  each  represent  a  separate  routing  protocol  governing  the  network. 
This  model’s  flexibility  is  the  ability  to  remain  a  valid  network  representation  with  only 
one  of  the  routing  protocols  included.  I  discuss  this  possibility  further  in  the  last  chapter. 

3.3.2. 1  Number  of  Lost  Calls  Objective  Function.  The  first  objective 
function  attempts  to  minimize  the  number  of  lost  calls.  This  metric  is  the  direct  opposite 
of  the  call  throughput  metric  measured  in  my  early  attempts  at  development  of  a  network 
performance  model.  The  number  of  lost  calls  metric  is  a  form  of  network  reliability. 

The  definition  of  reliability  has  always  been  difficult  to  define  and  evaluate,  but 
traditionally,  reliability  has  been  based  upon  some  measure  of  network  connectivity 
[27,13].  Sanso,  Soumis,  and  Gendreau  in  1991  proposed  a  new  measure  of  network 
reliability  based  upon  the  expected  number  of  lost  calls  due  to  failures  within  the 
telecommunication  network  [27]. 

I  think  this  measure  of  reliability  can  do  a  better  job  in  assessing  network 
performance  than  simple  connectivity  measures.  This  stems  from  the  fact  that  today’s 
communications  networks  have  extremely  high  connectivity  rates,  usually  greater  than 
99%  [27].  Additionally,  telling  the  user,  “Last  month,  twenty-three  phone  calls  were 
disrupted  and  eighteen  of  the  calls  were  of  the  highest  national  priority,  supporting 
national  policy  makers  during  a  contingency  operation,”  will  certainly  have  a  greater 
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meaning  to  the  customer  and  service  provider  than  saying,  “Your  calls  were  connected 
99.99%  of  the  time  last  month”. 

The  determination  of  priority  for  a  particular  commodity  is  accomplished  by  the 
constant  w”.  This  weight  would  need  to  be  assigned  by  the  network  operators,  users,  and 
senior  policy  makers. 

33.2.2  Shortest  Path  Objective  Function.  The  shortest  path  objective  is  a 
routing  discipline  for  the  model.  The  shortest  path  protocol  can  be  based  upon  minimum 
distance  or  upon  the  minimum  number  of  hops  (number  of  nodes  that  each  message  must 
traverse  in  reaching  its  destination)  [15:142].  The  shortest  path  routing  discipline  in  either 
formulation  also  helps  to  prevent  some  blocking  and  rerouting  problems  that  can  occur 
when  a  link  is  down  for  maintenance.  [27] 

Lx)gically,  the  shortest  path  criterion  could  conflict  with  the  objective  function 
(minimizing  data  delay)  since  the  shortest  path  requirement  could  force  flow  into  an 
already  crowded  link  and  consequently  increase  network  delay.  The  resolution  of  this 
problem  is  addressed  in  the  next  section. 

3. 3. 2. 3  Data  Delay  Objective  Function.  The  data  delay  measure  can  also 
be  referred  to  as  network  availability.  My  creation  of  the  measure  for  data  delay  stemmed 
from  adapting  the  formula  created  by  Kleinrock  [17,21]: 
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Delay  =  —  Y 


peOqeD 


PQ 


p^Oq^D 


pq 


where:  y  is  total  network  throughput; 


1  /  |j,  is  average  message  length 

By  making  the  assumption  that  call  duration  (y)  and  average  call  length  (|j,)  are  both  one, 
the  formula  is  transformed  into  the  formula  used  for  the  objective  function  presented  in  the 
model. 

The  nice  feature  of  this  formulation  is  that  it  forces  equity  in  proportion  of  flow 
over  each  link.  This  occurs  since  in  taking  the  minimum  of  the  function  these  proportions 
will  be  keep  as  small  as  possible.  Additionally,  each  link  is  prevented  from  reaching  its 
capacity  since  the  delay  tends  toward  infinity  at  capacity.  This  fact  is  somewhat  artificial, 
but  for  large  capacity  network  it  is  not  usually  a  problem.  Additionally,  this  problem 
could  easily  be  over  come  by  adding  a  one  to  the  capacity  in  the  denominator  of  the 
measure  if  the  link  tended  towards  complete  saturation. 

The  other  problem  created  by  this  objective  function  is  that  it  is  non-linear.  While 
there  certainly  are  software  packages  available  that  can  solve  formulations  that  have  linear 
constraints  and  non-linear  objective  functions  [6],  we  would  lose  the  advantage  of  the 
special  network  structure  for  ease  of  formulation  and  solution.  Therefore,  it  would  be 
better  to  have  a  linear  version  of  this  objective  function. 

This  can  be  accomplished  by  creating  an  approximation  of  the  function  for  delay. 
Simply  removing  the  flow  variable  from  the  denominator  of  the  objective  function  and 


3-15 


altering  the  ratio  accomplishes  this.  The  linear  approximation  to  the  original  delay 
objective  function: 

Delay  =  - 

Y  «  ViC, 

where:  y  is  total  network  throughput; 

1  /  p,  is  average  message  length 

This  new  objective  function  has  the  advantage  of  being  linear,  without  being  a 
major  conceptual  extension  of  the  original  delay  formula.  Additionally,  the  problem  of  the 
denominator  going  to  zero  in  the  original  ratio  is  eliminated.  Kleinrock’s  formula  had  the 
distinct  disadvantage  of  never  allowing  a  link  to  reach  capacity.  Obviously,  a  link  must  be 
able  to  operate  at  full  capacity. 

The  constraint  method  solution  approach  for  this  objective  function  would  be  to 
fold  the  objective  function  itself  into  the  constraint  set  using  a  known  delay  factor  as  an 
upper  bound  on  delay.  A  potential  source  for  the  upper  bound  on  delay  is  the  sponsor’s 
original  request  letter  stating  that  average  data  delay  for  the  network  must  be  less  than  .1 
seconds.  This  figure  comes  from  old  LOSA’s  between  network  users  and  operators.  The 
disadvantage  of  such  an  approach  is  that  the  solution  for  the  system  would  need  to  be 
recalculated  in  order  to  see  the  effect  of  each  data  delay  factor  the  sponsor  considers. 

The  constraint  method  usually  adds  another  constraint  to  the  constraint  set. 
However,  as  the  case  study  shows  in  the  next  chapter,  this  is  not  the  situation  with  this 
model  formulation.  When  the  network  delay  objective  function  is  incorporated  as  a  set  of 
constraints  to  represent  link  delay  for  each  hnk,  the  link  capacity  constraints  become 
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redundant  or  the  new  data  delay  constraints  are  themselves  redundant  depending  upon  the 
size  of  the  right-hand-side.  Thus,  the  size  of  the  overall  constraint  set  does  not  increase. 

While  I  will  include  data  delay  in  the  case  study,  my  research  has  indicated  that 
data  delay  probably  does  not  need  to  be  included  in  a  final  performance  evaluation  model. 
Such  routing  protocols  have  fallen  out  of  favor  and  shortest  path  formulations  based  upon 
minimum  number  of  hops  (node  crossings)  have  become  more  widely  accepted  as  the 
better  protocol  [15:142-3]. 

3. 3.2.4  Network  Constraint  Set.  The  network  model  constraints  were 
formulated  by  Sanso,  et  al.  [27].  There  are  two  principal  kinds  of  constraints  for  the 
network:  limits  upon  link  capacity  and  conservation  of  flow  for  the  nodes. 

The  link  capacity  constraints  have  the  job  of  limiting  the  amount  of  flow  upon  each 
link  of  the  network.  This  is  an  obvious  requirement  since  in  real  life  there  is  a  physical 
limit  to  the  amount  of  flow  possible  upon  a  communications  network.  Assuming  simple 
circuit  switching,  a  link  only  has  a  finite  number  of  data  lines  within  in  it. 

I  have  added  an  additional  variable  to  the  link  capacity  constraints,  that  being  the 
“a”  value  as  discussed  previously.  My  purpose  of  this  variable  is  to  represent  the  amount 
of  time  long-term  that  the  link  is  down  for  maintenance.  This  method  is  not  without 
problems  however.  The  proportion  does  not  actually  tell  the  user  when  during  the  interval 
the  link  is  unavailable,  but  instead  gives  an  average.  If  the  maintenance  scheduling  office 
wanted  to  determine  the  effect  upon  network  operations  of  taking  a  link  down  for 
maintenance  in  a  specific  time  period,  a  better  approach  would  be  to  set  the  capacity  of  a 
link  determined  to  be  down  for  maintenance  in  a  time  period  to  zero  and  then  solve  the 
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network  over  several  time  periods,  creating  a  new  constraint  set  for  each  time  period. 

This  would  require  the  addition  of  a  new  time  subscript  “t”  in  the  model,  as  shown  in 
Figure  3.3  Time-Interval  Performance  Network. 

The  conservation  of  flow  constraints  for  both  models  are  different  from  most 
network  flow  models  since  each  node  can  experience  “loss”  of  calls.  Traditionally, 
network  models  require  flow  in  to  equal  flow  out  of  a  node,  but  this  may  not  always  be 
the  case  when  dealing  with  communication  networks.  In  this  case  we  are  interested  in  the 
number  of  calls  that  are  lost  due  to  link  maintenance.  This  problem  of  imbalanced  flow  is 
eliminated  by  the  inclusion  of  variable  to  count  the  number  of  lost  calls.  This  variable 
serves  the  purpose  of  letting  the  lost  call  “flow  out”  of  the  node,  and  maintain  nodal 
conservation. 


3-18 


(Number  of  Lost  Calls) 


where  Traffic  flow  of  O  -  D  in  period  t  (p  =  origin  &  q  =  destination  using  ar 

C„  Capacity  of  arc  u  in  time  period  t; 
d*^  Origin  -  destination  offered  load  in  time  period  t; 

Y'’*’*  Origin  -  destination  lost  traffic  in  time  period  t; 

r(0  Set  of  arcs  whose  origin  node  is  i; 
r  -  (i)  Set  of  arcs  whose  terminal  node  is  i; 

w  Weighting  priority  given  to  the  p  -  q  commodity  for  period  t; 

1„  Length  of  arc  between  nodes; 

O  Origin  node  set; 

D  Destination  node  set; 

N  Node  set  for  network; 

M  Arc  (hnk)  set  for  network. 

T  Set  of  time  intervals  t 

Figure  3.3  Time -Interval  Performance  Network 
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These  formulations  are  not  without  problems.  As  pointed  out  by  Sanso,  et  al,  the 
first  model  as  formulated  needs  O(n^)  constraints  and  0(n'‘)  variables,  where  n  is  the 
number  of  nodes  in  the  network  [27].  Even  a  small  network  of  ten  nodes  would  therefore 
have  1,000  constraints  and  10,000  variables.  Additionally,  the  second  model  formulation 
increases  the  number  of  variables  to  0(tn'').  Which  means  the  small  ten  node  network 
requires  approximately  240,000  variables.  Obviously,  it  is  better  if  a  network  solver 
package  of  some  kind  can  be  used  that  takes  advantage  of  the  special  structure  a  network 
tableau  creates.  Even  today’s  best  commercial  linear  programming  packages  would  get 
bogged  down  by  a  hundred  node  network,  which  is  still  a  small  communications  network 
by  today’s  standards. 

3.4  Solution  Algorithm 

The  previous  sections  highlight  how  each  part  of  the  problem  is  solved.  The  next 
step  is  to  show  how  each  part  is  linked  together  and  iterated  to  find  a  solution.  The 
solution  algorithm  for  the  entire  model  is  presented  in  Appendix  E. 

Step  (1):  Optimize  operator  perspective 

(1.1)  Choose  number  of  maintenance  depots  (M)  to  be  located. 

(1.2)  Network  partitioning  algorithm  to  create  M  subnetworks  among 
the  N  nodes,  where  N  is  the  number  of  nodes. 

(1.3)  Subnetwork  location  algorithm  to  locate  a  single  facility  within  the  M 
subnetworks.  RESULTS:  S  =  optimal  location  solution. 

The  optimal  solutions  is  chosen  according  to  the  minimum  time-to-respond 
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objective. 

Step  (2):  Optimize  user  perspective 

(2.1)  Create  network  maintenance  schedule  for  solution  from  Step  1.3 

(2.2)  Run  network  user  performance  model  for  solution  from  Step  1.3  without 
network  delay  factor. 

(2.3)  IF  (Delay  Factor  Desired)  THEN  Create  efficient  frontier  incorporating 
by  varying  the  network  delay  factor  over  the  desired  range. 

The  next  chapter  will  discuss  the  application  of  this  solution  algorithm  and  any  necessary 
extensions  that  can  be  made  to  improve  upon  it. 
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IV.  Case  Study 


This  chapter  contains  a  case  study  to  demonstrate  the  solution  algorithm  for 
improving  maintenance  depot  location  and  network  operations.  The  experiment  solves  a 
small-sized  network  similar  in  configuration  and  commodity  flow  to  that  which  the 
sponsoring  agency  uses. 

4.1  Location  Algorithm 

The  network  this  case  study  solves  is  shown  in  Figure  4.1.  This  network 
consists  of  five  nodes  and  seven  arcs.  The  distance  ( dj j )  from  node  i  to  node  j  is  shown 

along  each  arc  in  the  figure.  The  service  call  arrival  rates  for  each  node  are  also  shown. 

Figure  4.1.  Small  Network 


The  network  topology  for  the  location  algorithm  and  for  the  flow  model  are  the 
same.  This  assumption  means  the  message  flow  through  the  network  will  use  the  same 
arcs  as  the  maintenance  service  providers. 
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The  application  of  the  location  model  requires  several  steps  as  described  in 
Chapter  3. 

Step  #1.1:  Choose  the  number  (M)  of  maintenance  depots  to  be  located 
within  the  communications  network.  I  choose  M  =  2.  Therefore,  the  h  =  .50  and  the 
tolerance  (a)  is  set  to  .10. 

Step  #1.2:  Partitioning  algorithm.  This  algorithm  is  broken  into  two 
phases,  I  and  n.  Phase  I  is  a  complete  enumeration  of  the  possible  subnetworks.  The 
maximum  distance  for  compactness  is  arbitrarily  set  at  P  =  150  (which  is  arbitrarily  chosen 
to  demonstrate  the  elimination  of  a  possible  subnetwork  because  of  proximity  concerns, 
that  being  a  subnetwork  consisting  of  Nodes  1-2-4).  The  Phase  I  subnetwork  set  is  shown 
in  Appendix  A,  page  1 . 

The  second  phase  implements  the  model  described  in  section  3. 3. 1.1.  The  model  is 
formulated  and  solved  using  the  EXCEL  Spreadsheet.  The  formulation  and  solution  are 
shown  in  Appendix  A,  pages  2-3,  respectfully.  The  results  of  this  application  are  two 
subnetworks  in  which  the  maintenance  depots  are  to  be  located.  The  best  partition 
possible  consists  of  Nodes  1-3  and  2-4-5.  This  means  that  one  depot  is  located  at  node  1 
or  3,  while  the  other  is  located  at  node  2, 4,  or  5. 

Step  #  1.3:  Location  algorithm.  The  number  of  possible  solutions  for  this 
problem  is  6.  This  stems  from  the  combination  of  possible  locations  for  a  maintenance 
depot  within  each  of  the  subnetworks:  (1  &  2),  (1  &  4),  (1  &  5),  (3  &  2),  (3  &  4), 
and  (3  &  5). 
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The  location  calculations  are  accomplished  in  Appendix  A,  pages  4-6  using 
MATHCAD.  Table  4.1  shows  the  possible  combination  of  locations  and  the  associated 
service  call  response  times  for  each  location  in  preferred  order. 


Table  4.1  Location  Combinations 


Depot  Locations; 
Nodes  i  &  j 

Min-Time-to-Respond 

(Hours) 

3  &  5 

0.924  &  3.715 

1  &  5 

1.263  &  3.715 

3  (fe  2 

0.924  &  4.877 

1  &  2 

1.263  &  4.877 

3  &  4 

0.924  &  Infinite 

1  &  4 

1.263  &  Infinite 

Obviously,  locating  the  maintenance  depot  at  node  4  in  the  second  subnetwork 
would  be  a  major  mistake  since  the  network  would  eventually  be  unable  to  perform 
maintenance  operations  upon  node  2, 4,  and  5  due  to  an  infinite  queue  building  up  waiting 
for  service  calls.  This  implies  that  no  messages  would  be  able  to  flow  through  these 
nodes.  Therefore,  it  is  possible  to  conclude  that  these  two  solutions  are  dominated  and 
there  are  four  possible  solutions  (S  =  4)  that  must  be  examined  for  flow  optimality. 


4.2  Flow  Model. 

The  network  representation  depicting  message  flows  is  shown  in  Figure  4.2.  Each 
flow  arrow  represents  a  different  type  of  multi-commodity  flow. 
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Figure  4.2.  Multi-Commodity 
Fiow  Orientation 


Step  #2.1  Create  Network  Maintenance  Schedule  for  Step  1.3  Solution. 
This  application  of  the  solution  algorithm  uses  the  reliability  factor  ( ajj )  and  the  model 

depicted  in  section  3.3.2  User  Performance  Model.  Table  4.2(a)  shows  the  impact  in 
reliability  measures  and  decreased  capacity  for  each  link  that  results  from  using  the 
optimal  solution  set  in  Table  4.1  (depots  located  at  node  3  &  5)  to  derive  a  maintenance 
schedule. 


Table  4.2(a)  Solution  #1  Schedule  Impact  (Location  3  &  5) 


Node 

i 

From 

To 

Rehabihty 

(a^j) 

Previous 

Capacity 

New 

Capacity 

1 

1 

3 

96.2% 

50 

48 

2 

1 

5 

80.7% 

50 

40 

3 

5 

2 

84.5% 

50 

42 

4 

2 

3 

80.7% 

50 

40 

5 

1 

4 

80.7% 

50 

40 

6 

3 

4 

80.7% 

50 

40 

7 

2 

4 

84.5% 

50 

42 
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The  calculation  of  the  reliability  measure  and  hence  the  impact  on  the  schedule  is 
shown  in  Appendix  B,  page  1-5  for  all  four  possible  solutions.  In  general,  the  creation  of 
a  real  maintenance  schedule  is  important  for  actual  operations  and  the  long-term  goal  of 
the  sponsor.  However,  for  this  exercise,  the  assumptions  that  create  a  given  maintenance 
schedule  are  not  critical.  It  is  more  important  that  the  assumptions  and  calculations 
remain  consistent  for  each  solution  schedule  so  that  a  reasonable  basis  for  comparison  can 
be  made.  The  assumptions  are: 

(1)  the  schedule  is  based  upon  continuous  24-clock  and  operations,  where  each 
schedule  represents  a  single  24-hour  period; 

(2)  the  average-time-to-respond  calculated  in  the  location  calculation  is  translated 
directly  into  a  reliability  measure  for  scheduling  purposes;  and, 

(3)  the  affect  upon  links  between  each  subnetwork  are  cumulative  (incorporating 
both  maintenance  depots  and  both  average-time-to-respond  approximations).  For 
example,  link  #2  from  Table  4.2.a.  is  impacted  by  both  subnetworks  since  it  connects  two 
nodes  of  different  subnetworks. 

Step  #  2.2  Run  Network  User  Performance  Model.  The  message 
flow  model  is  implemented  and  solved  using  SAS/OR  and  the  NETFLOW  procedure. 
The  case  study  network  can  be  seen  in  Appendix  B,  pages  6-8,  in  the  proper  SAS 
implementation  code. 

The  SAS/OR  model  formulation  requires  two  alterations  to  the  3.3.2  User 
Performance  Model,  presented  previously  in  order  to  run  in  the  SAS/OR  environment: 

(1)  the  delay  objective  function  must  be  incorporated  as  a  constraint;  and,  (2)  the  number 
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of  lost  calls  objective  function  is  incorporated  as  a  slack  external  flow  (which 
accomplishes  the  objective  function  and  maintains  network  conservation  of  flow).  These 
changes  are  reflected  in  the  formulation  shown  in  Appendix  B,  pages  6-8.  The  SAS 
software  package  solves  networks  of  the  following  form: 

min  c^x  +  d^z 

subject  to:  Fx  =  b 

Hx  +  Qz  <  =  >r 
1  <x<u 

Itl  <  Z  <  V 

where:  c  is  the  a  x  1  objective  function  cost  vector 

X  is  the  a  X  1  arc  variable  value  vector 
d  is  the  g  X  1  objective  function  coefficient 
vector  of  nonarc  variables 
z  is  the  g  X  1  nonarc  variable  value  vector 
F  is  the  totally  unimodular  n  x  a  node-arc 
incidence  matrix  of  the  network 
b  is  the  n  X  1  node  supply/demand  vector 
H  is  the  k  X  a  side  constraint  coefficient 
matrix  for  arc  variables 
Q  is  the  k  X  g  side  constraint  coefficient 
matrix  for  nonarc  variables 
1  is  the  a  X  1  arc  lower  flow  bound  vector 
u  is  the  a  X  1  arc  upper  flow  bound  vector 
m  is  the  g  X  1  nonarc  variable  lower  bound 
V  is  the  g  X  1  nonarc  variable  upper  bound 

Figure  4.3  SAS/OR  NETFLOW  Implementation  Format 


The  solution  generated  by  the  SAS/OR  software  package  is  shown  in  Appendix  B, 
pages  9-10.  The  solution  set  traces  out  the  path  each  commodity  takes  between  origin 
and  destination.  Table  4.2(b)  depicts  the  solution  set  by  the  five  different  commodity 
types.  This  table  indicates  that  all  flows  made  it  through  the  network  except  commodity 
type  C,  which  lost  20  calls. 
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Table  4.2(b)  Solution  #1;  Lost  Calls 


Origin 

i 

np^^nmii 

Number 

Sent 

Number 

Delivered 

Number 

Lost 

A 

1 

4 

30 

30 

0 

B 

2 

1 

30 

30 

0 

C 

3 

5 

30 

10 

20 

D 

4 

5 

30 

30 

0 

E 

5 

2 

30 

30 

0 

Total 

150 

130 

20 

Step  #2.3  Create  Delay  Efficient  Frontier.  The  creation  of  the  efficient 
frontier  involves  the  selection  of  different  delay  factor  values.  These  values  are  used  to 
create  the  right-hand-side  for  the  new  set  of  link  delay  constraints.  The  new  RHS 
calculations  are  accomplished  in  MATHCAD  and  shown  in  appendix  B,  pages  11-13. 

The  selected  values  for  data  delay  and  the  resulting  impact  upon  RHS  values  are 
shown  in  Table  4.3.  This  table  indicates  that  the  effect  of  the  average  link  delay  does  not 
start  to  impact  the  model  solution  until  the  allowable  delay  is  less  than  .05  seconds.  The 
table  also  shows  the  dramatic  impact  a  network  delay  of  less  than  .01  seconds  has  upon 
link  capacity.  This  impact  translates  into  123  lost  calls,  as  Appendix  B,  pages  17  - 18 
show. 


Table  4.3  Delay  Constraint  RHS  Values 


Link 

Capacity 

Data  Delay  (seconds) 

Node  i  to 

j 

None 

.01 

.05 

.10 

1  -3 

48 

10 

51 

102 

1-4 

40 

8 

42 

85 

1-5 

40 

8 

42 

85 

2-3 

40 

8 

42 

85 

2-4 

42 

9 

45 

90 

2-5 

42 

9 

45 

90 

3-4 

40 

8 

42 

85 
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As  shown  in  Figure  4.4,  the  efficient  frontier  for  data  delay  at  these  three  link  delay 
factors  is  a  set  containing  three  points.  The  original  solution  from  Step  #2.2  provides  two 
points  (since  the  delay  constraints  are  redundant  for  the  delay  values  of  .05  and .  10 
seconds).  The  third  point  is  the  solution  generated  by  using  the  new  capacity  limits 
imposed  by  the  delay  factor  of  .01  seconds.  Obviously,  if  more  points  are  desired  for  the 
decision  maker’s  evaluation,  it  is  necessary  to  solve  the  model  using  more  delay  factor 
values  less  than  .05  seconds. 


Delay  (Sec's) 

Figure  4.4  Efficient  Frontier  with  Data  Delay 


This  demonstrates  the  complete  algorithm  and  its  application  to  a  small-sized 
network.  However,  one  thing  must  still  be  proven:  existence  of  a  win-win  situation 
between  the  operator  and  user  model. 


4.3  Win-Win  Situation 

The  win-win  situation  occurs  if  the  optimum  operator  location  for  the  maintenance 
depot(s)  also  creates  the  optimum  performance  for  the  user  network  flow  model.  The  key 
assumption  for  the  win-win  situation  is  the  FIFO  maintenance  queue.  The  idea  that  while 
one  maintenance  operation  is  being  acted  upon,  any  other  maintenance  service  calls  that 
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arrive  go  into  a  maintenance  queue.  The  maintenance  service  calls  receive  service  in  the 
order  in  which  they  arrive  to  the  queue.  If  this  maintenance  scheduling  protocol  is  not 
followed  and  some  other  queuing  discipline  is  utilized,  the  win-win  situation  is  not 
guaranteed. 

The  win-win  case  intuitively  appears  to  be  true.  The  minimum-time-to-respond 
objective  for  the  operator  perspective  selects  the  maintenance  depot  location  that  allows 
maintenance  operations  to  be  performed  as  quickly  as  possible.  This  allows  the  network 
to  operate  for  a  longer  proportion  of  time,  and  hence  each  link  has  a  higher  reliability 
measure.  A  higher  reliability  measure  translates  into  less  capacity  lost. 

The  user  performance  model  attempts  to  minimize  the  number  of  lost  calls,  take 
the  shortest  path  possible,  and  induce  as  little  delay  as  possible  upon  network  flow.  Total 
network  and  individual  link  capacities  are  the  major  factors  for  all  three  of  these  objectives 
(assuming,  of  course,  the  network  is  capacitated).  Obviously,  anything  that  decreases 
capacity  in  a  capacitated  network  will  increase  the  number  of  lost  calls,  possibly  require 
longer  paths  between  origin  and  destination,  and  definitely  increase  delay  due  to  increases 
in  link  volume. 

The  concept  of  a  win-win  situation  existing  between  the  optimum  operator  value 
and  the  optimum  user  value  is  essential  to  the  success  and  usefulness  of  the  designed 
algorithm.  If  a  win-win  situation  does  not  exist,  the  algorithm  is  forced  to  enumerate  each 
possible  location  and  combination  of  locations  for  the  maintenance  depot(s)  within  the 
network.  This  type  of  an  algorithm  is  inefficient  and  requires  an  extreme  amount  of  time 
to  complete  even  for  a  small  network.  The  next  two  subsections  offer  a  demonstration  of 
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the  win-win  for  the  other  five  possible  location  combinations  from  the  five  node  network 
and  a  mathematical  proof  of  the  win-win  concept. 

4.3.1  Case  Study:  Win-Win  Example.  The  case  study  creates  six  possible  location 
combinations  for  the  maintenance  depots  (see  Table  4.1,  Location  Combinations). 

Ignoring  the  two  locations  containing  node  4  (since  the  queue  builds  to  an  infinite  size) 
and  using  the  remaining  three  location  combinations,  the  following  schedule  tables  help 
illustrate  the  win-win  example  (calculation  for  these  tables  is  shown  in  Appendix  B, 
pages  1-5: 


Table  4.4(a)  Solution  #2  Schedule  Impact  (Location  1  &  5) 


Node 

i 

From 

To 

ReUabUity 

(a^j) 

Previous 

Capacity 

New 

Capacity 

1 

1 

3 

94.7% 

50 

47 

2 

1 

5 

79.2% 

50 

39 

3 

5 

2 

84.5% 

50 

42 

4 

2 

3 

79.2% 

50 

39 

5 

1 

4 

79.2% 

50 

39 

6 

3 

4 

79.2% 

50 

39 

7 

2 

4 

84.5% 

50 

42 

Table  4.5(a)  Solution  #3  Schedule  Impact  (Location  3  &  2) 


Node 

i 

From 

To 

Reliability 

(a^j) 

Previous 

Capacity 

New 

Capacity 

1 

1 

3 

96.2% 

50 

48 

2 

1 

5 

75.9% 

50 

37 

3 

5 

2 

79.7% 

50 

39 

4 

2 

3 

75.9% 

50 

37 

5 

1 

4 

75.9% 

50 

37 

6 

3 

4 

75.9% 

50 

37 

7 

2 

4 

79.7% 

50 

39 
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Table  4.6(a)  Solution  #4  Schedule  Impact  (Location  1  &  2) 


Node 

i 

From 

To 

Rehabihty 

(aij) 

Previous 

Capacity 

New 

Capacity 

1 

1 

3 

94.7% 

50 

47 

2 

1 

5 

74.4% 

50 

37 

3 

5 

2 

79.7% 

50 

39 

4 

2 

3 

74.4% 

50 

37 

5 

1 

4 

74.4% 

50 

37 

6 

3 

4 

74.4% 

50 

37 

7 

2 

4 

79.7% 

50 

39 

Using  the  SAS/OR  software  package  and  repeating  Step  #2.2  again  for  each 
solution,  (see  Appendix  C,  page  1-9  for  SAS  coded  networks)  the  results  are  displayed  in 
the  next  three  tables  (4.4(b),  4.5(b),  and  4.6(b)).  These  solutions  highlight  existence  of  a 
win-win  situation  very  well.  Each  solution  shows  an  increasing  number  of  lost  calls  as  the 
minimum-time-to-respond  increases.  Appendix  C,  pages  10-15,  also  contain  the  solution 
in  SAS  form.  (The  SAS  output  is  useful  for  path  determination.) 


Table  4.4(b)  Solution  #2;  Lost  Calls 


Origin 

i 

Number 

Sent 

Number 

Dehvered 

Number 

Lost 

A 

1 

4 

30 

30 

0 

B 

2 

1 

30 

30 

0 

C 

3 

5 

30 

8 

22 

D 

4 

5 

30 

30 

0 

E 

5 

2 

30 

30 

0 

Total 

150 

128 

22 

Table  4.5(b)  Solution  #3;  Lost  Calls 


Origin 

i 

Number 

Sent 

Number 

Delivered 

Number 

Lost 

A 

1 

4 

30 

30 

0 

B 

2 

1 

30 

30 

0 

C 

3 

5 

30 

4 

26 

D 

4 

5 

30 

30 

0 

E 

5 

2 

30 

30 

0 

Total 

150 

124 

26 
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Table  4.6(b)  Solution  #4;  Lost  Calls 


Origin 

i 

Number 

Sent 

Number 

Delivered 

Number 

Lost 

A 

1 

4 

30 

30 

0 

B 

2 

1 

30 

30 

0 

C 

3 

5 

30 

3 

27 

D 

4 

5 

30 

30 

0 

E 

5 

2 

30 

30 

0 

Total 

150 

123 

27 

These  tables  indicate  an  increasing  number  of  lost  calls  as  we  move  down  the 
location  list.  These  results  are  consistent  with  the  win-win  theory.  But,  these  numbers 
only  show  it  for  the  without  delay  metric  included.  For  there  to  be  a  total  win-win  it  must 
hold  for  both  metrics. 

The  delay  constraint  development  and  calculation  for  the  three  locations  is  shown 
in  Appendix  D,  pages  1-9.  These  calculations  show  the  effect  of  the  different  link  delay 
factors.  Tables  4.7(a),  (b),  and  (c)  indicates  the  delay  constraint  values  for  each  possible 
solution  location: 

Table  4.7(a)  Delay  Constraint  RHS  Values  (Location  1  &  5) 


Link 

Capacity 

Data  Delay  (seconds) 

Node  i  to 

j 

None 

.01 

.05 

.10 

1  -3 

47 

10 

51 

102 

1-4 

39 

8 

42 

85 

1-5 

39 

8 

42 

85 

2-3 

39 

8 

42 

85 

2-4 

42 

9 

45 

90 

2-5 

42 

9 

45 

90 

3-4 

39 

8 

42 

85 
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Table  4.7(b)  Delay  Constraint  RHS  Values  (Location  3&  2) 


Table  4.7(c)  Delay  Constraint  RHS  Values  (Location  1  &  2) 


These  tables  show  the  same  pattern  as  the  data  from  the  first  solution.  The  delay 
factor  does  not  come  into  play  until  the  delay  is  set  to  less  than  .05  seconds.  Table  4.8 
shows  the  resulting  impact  to  lost  calls.  The  solutions  are  generated  as  before  in  SAS  and 
shown  in  Appendix  D,  pages  10-15. 

Table  4.8  All  Solutions:  Number  of  Lost  Calls  (With  Delay) 


If  a  win-win  situation  exists  a  plot  of  the  different  location  values  should  create  a 
graph  similar  to  Figure  4.5.  Basically,  the  different  location  contours  should  not  cross 
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each  other.  Each  contour  line  should  start  at  the  maximum  number  of  lost  calls  possible 
(total  throughput)  and  bottom  out  into  a  horizontal  line  as  allowable  link  delay  is  increased 
to  a  breakpoint  where  it  no  longer  changes  network  capacity  constraints.  (Remember, 
network  capacity  constraints  and  link  delay  constraints  are  redundant.)  If  the  lines  do  not 
cross  one  of  the  contours  would  thus  dominate  all  of  the  others  by  achieving  a  lower 
number  of  lost  calls  at  a  smaller  link  delay  value. 


Delay  (Sec's) 

Figure  4.5  Theoretical  Efficient  Frontier  for  Win-Win  Situation 

The  data  from  Table  4.8  translate  into  Figure  4.6.  This  figure  presents  the  win-win 
situation  in  dramatic  fashion.  Each  contour  line  represents  a  different  location  solution. 

As  the  graph  indicates  these  line  follow  the  expected  pattern  very  closely.  The  reason  two 
sets  of  these  contours  touch  at  the  delay  value  of  .01  is  due  to  the  level  of  the  inputs  used 
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in  the  test.  This  point  requires  further  explanation  since  it  would  seem  to  indicate  that  the 
win-win  condition  described  above  might  be  violated. 


Figure  4.6  Case  Study  Actual  Efficient  Frontier 

Table  4.8  indicates  that  the  number  of  lost  calls  at  the  data  delay  of  .01  seconds  did 
not  change  between  location  (3  &  5)  and  (1  &  5).  This  is  due  to  the  assumption  I  use 
when  calculating  capacities:  truncation  of  all  link  capacities  (rounding  down).  I  use  this 
assumption  so  that  only  complete  calls  can  get  through  (e.g.  no  fractional  calls). 

For  example,  suppose  the  calculation  of  delay  RHS  values  for  Location  (3  &  5) 
versus  (1  &  5)  yielded  a  link  capacity  value  of  39.996  and  39.002,  respectfully.  Both 
values  are  rounded  down  to  39.  This  has  the  effect  of  changing  the  number  of  lost  calls 
for  the  two  model  runs  and  subsequently  a  slight  alteration  of  the  slope  for  each  contour 
line.  Now  imagine  if  the  inputs  for  number  of  calls  and  initial  link  capacities  had  been  one 
or  more  orders  of  magnitude  larger  (which  is  quite  reasonable  given  the  size  and  capacity 
of  present  communication  networks)  the  truncation  effect  would  not  be  so  pronounced, 
and  it  would  be  possible  to  observe  the  real  differences  in  the  results.  Obviously,  the 
truncation  error  becomes  more  pronounced  as  the  size  of  the  inputs  is  decreased. 

4.3.2  Win-Win  Proof.  One  way  to  prove  the  win-win  situation  is  by  showing  that 
the  operator  and  user  models’  objective  functions  are  based  upon  similar  factors.  This 
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proof  will  show  that  both  models  are  optimized  by  achieving  maximum  available  arc 
capacity.  This  proof  assumes  a  capacitated  network. 


Operator  (Location)  Objective  Function: 

Optimization  factor  =  Minimum-time-to-respond  (MTR)  to  service  call 

r,  •  j  T  •  1  T-.  1-  1--1-  MTR 

Penod  Link  Reliability  =  - 

Time  Units  /  Period 

Period  Link  Capacity  =  Period  Link  Reliability  *  Maximum  Link  Capacity 

User  (Flow)  Performance  Objective  Function:  (Per  Individual  Link) 

Objective  1:  Number  of  Lost  Calls 

Max  Number  Calls  =  Period  Link  Capacity 

Number  Lost  Calls  =  Total  Calls  Required  on  Link  -  Max  Number  Calls 

Objective  2:  Shortest  Path 

The  shortest  path  is  chosen  from  the  set  of  possible  paths  P  that  connect 
origin  i  to  destination  j,  where  a  path  is  defined  as  the  number  of  links 
required  to  span  from  i  to  j.  A  path  is  defined  if  there  is  capacity  remaining 
for  each  link  (Period  Link  Capacity)  within  the  path.  Therefore,  as  the 
capacity  of  the  shortest  path  in  each  set  P  is  consumed  a  longer  path  from 
the  set  P  is  chosen. 

Objective  3:  Network  Delay 

, 

Delay  =  - 

Y 

where:  y  is  total  network  throughput; 

1  /  p,  is  average  message  length 

As  the  link  delay  formula  shows,  as  (period)  link  capacity,  ,  increases 
the  value  of  Delay  will  decrease,  all  other  variables  remaining  constant. 
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This  proof  shows  that  each  objective  function  in  the  user  performance  model 
depends  directly  upon  the  time  period  link  capacity  generated  from  the  operator  location 
model.  Therefore,  as  MTR  is  minimized,  period  link  capacity  is  increased,  and  all  three 
objective  functions  are  optimized. 

The  example  and  the  proof  demonstrate  the  important  feature  of  this  algorithm: 
the  operator  versus  user  trade-off  can  be  complimentary  (win-win).  The  use  of  the  FIFO 
queuing  system  for  dynamic  scheduling  of  maintenance  operations  is  the  necessary 
protocol  to  insure  the  win-win  situation. 
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V.  Conclusions  and  Recommendations 


This  chapter  presents  the  research  conclusions  and  recommendations  for  future 
research  efforts. 

5.1  Conclusions 

Even  though  this  research  effort  was  centered  upon  a  small  piece  of  a  new  and 
large  problem  for  the  sponsor,  I  was  able  to  make  several  observations. 

First,  the  network  performance  model  measuring  message  “flow”  makes  it 
possible  to  assess  the  impact  to  network  operations  caused  by  changes  in  the  maintenance 
schedule.  One  of  the  problems  the  sponsor  faces  is  the  inability  to  quantify  the  impact  to 
network  operations  when  the  maintenance  schedule  changes.  The  creation  of  a  network 
performance  model  to  measure  different  metrics  (forms  of  reliability  and  availability) 
makes  this  assessment  possible.  Two  separate  performance  models  were  created  for  this 
purpose.  The  first  model  (demonstrated  in  the  case  study)  observes  the  network  from  an 
aggregate  level,  while  the  second  model  implements  a  specific  maintenance  schedule  for 
a  specified  length  of  time.  The  two  models  should  prove  useful  for  evaluating  “what-if  ’ 
situations  and  specific  maintenance  schedules.  The  ability  to  quantify  the  impact  of 
maintenance  schedule  changes  is  the  first  important  step  toward  the  goal  of  creating  an 
automated  maintenance  scheduling  system. 

Second,  the  performance  metric  of  total  number  of  lost  calls  is  probably  a  better 
metric  than  measuring  average  network  delay.  The  number  of  lost  calls  metric  allows 
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both  system  operators  and  users  to  better  assess  network  performance.  This  metric  goes 
beyond  a  simple  measure  of  reliability  since  it  shows  which  messages  would  be  lost.  The 
delay  metric  may  not  be  very  meaningful  to  the  network  evaluators  since  a  time  delay  of 
a  few  himdredths  of  a  second  is  not  dramatic.  However,  the  incorporation  of  the  delay 
metric  as  a  constraint  can  have  large  impact  upon  network  performance.  As  the  case 
study  results  demonstrate  there  is  a  trade-off  between  the  number  of  lost  calls  and  average 
link  delay  (as  allowable  link  delay  is  decreased  the  number  of  lost  calls  will  increase). 

The  level  at  which  average  link  delay  begins  to  affect  the  number  of  lost  calls  will  be 
different  for  each  network  analyzed. 

Third,  the  location  of  maintenance  depots  using  a  metric  geared  toward  the 
system’s  operators  can  produce  positive  benefits  for  the  user  of  a  system.  I  found  that 
under  the  right  set  of  circumstances  (first-in-first-out  dynamic  maintenance  protocols, 
steady-state  operations,  and  no  priority  maintenance)  an  optimal  location  of  maintenance 
service  depots  based  upon  the  minimum-time-to-respond  can  improve  network 
performance  by  reducing  the  time  required  to  perform  maintenance  operations. 

5.2  Recommendations 

Since  this  was  the  beginning  of  a  much  longer  research  effort  for  the  sponsor, 
there  are  a  tremendous  number  of  areas  needing  further  research.  I  will  confine  myself  to 
a  few  of  the  important  ones  that  stem  directly  from  this  research: 

(1)  Creation  and  development  of  a  large-scale  telecommunication  network  that 
accurately  depicts  network  operations.  This  network  would  need  to  accommodate  a  few 
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hundred  commodities  and  forty  nodes.  This  would  allow  testing  of  the  network 
measurement  metrics  (lost  calls,  delay,  and  any  others).  It  may  be  necessary  to  move  to  a 
simulation  environment  since  the  size  of  this  type  of  network  might  very  well  go  beyond 
even  the  best  network  solving  software  packages  and  become  largely  intractable.  A 
simulation  approach  has  several  advantages  if  underpinned  with  a  good  theoretical 
development. 

(2)  Development  of  metrics  for  measuring  network  performance  levels  which  are  useful 
to  both  the  operator  and  user.  Metrics  supporting  the  operator  should  be  able  to  tell  the 
operator  if  maintenance  resources  are  being  utilized  efficiently,  or  if  all  necessary  support 
agreements  (LOSAs)  are  being  met.  Good  user  metrics  should  be  able  to  tell  if  LOSAs 
are  being  satisfied.  But,  more  importantly,  these  new  metrics  need  to  give  the  users 
specific  information  about  different  messages  and  data.  (For  example,  whose  messages 
are  lost  or  interrupted,  what  were  the  priority  levels  of  the  messages,  etc.) 

(3)  Extension  of  the  model  to  eliminate  some  of  the  simplifying  assumptions.  Since  this 
was  a  new  topic  area,  I  had  to  make  many  simplifying  assumptions  in  order  to  prove 
basic  concepts.  Now  there  is  an  opportunity  to  go  beyond  these  assumptions  in  order  to 
improve  the  model.  An  example  of  a  simplifying  assumption  that  needs  to  be  altered  is 
the  current  FIFO  maintenance  protocol.  The  inclusion  of  more  detail  is  important  if  the 
model  is  going  to  have  the  fidelity  necessary  to  handle  real  world  operations. 

(4)  Development  of  an  interactive  scheduling  tool.  This  tool  should  allow  the  operator  to 
create  a  maintenance  schedule  and  put  it  into  a  data  structure  that  the  network 
performance  model  can  utilize  to  test  how  good  the  schedule  is.  This  would  then  allow 
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the  operator  to  parametrically  alter  the  schedule  and  evaluate  the  impact  of  schedule 
changes  in  both  quantitative  and  qualitative  metrics.  The  tool  would  achieve  the  ultimate 
objective  of  performing  dynamic  maintenance  scheduling  for  the  telecommunication 
system. 
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Appendix  A.  Location  Model 


A.1  Partitioning  Phase  I 
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A.2  Partitioning  Model  Setup 
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0.2 

0.2 

0.2 

0.2 

0.2 

Node  2  = 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

Node  3  = 

0.25 

0.25 

0.25 

0.25 

0.25 

0.25 

0.25 

Node  4  = 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

Node  5  = 

0.35 

0.35 

0.35 

0.35 

0.35 

0.35 

0.35 

Link  Connection 
Node  1 
Node  2 
Nodes 
Node  4 
Nodes 


Link  RHS 

Sub  1  Sub  2  Sub  3  Sub  4  Sub  5  Sub  6  Sub  7  Used  Links  Limits 


110  0  1 
10  110 
10  10  1 
0  0  10  0 
0  10  10 


10  0  1 
0  10  1 
10  0  1 
110  1 
0  10  1 


Mutual  exclusivity 
Constraint 


#  of  Subs  Required  # 
Chosen  Subnetworks 
0  2 


Link  Variable 


Objective 


0  0  0 


1  1  1 


0  0  0 


1  1  1 


Total 
Value 
of  Function 
1  0 
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A.  3  Partitioning  Model  Setup 


M  = 

2  2  2  2  2 

2  2 

a  = 

Objective 

0.1  0.1  0.1  0.1  0.1 

0.1  0.1 

Node  Proportion 
Nodel  = 

0.2 

0.2 

0.2 

0.2 

0.2 

0.2 

0.2 

Node  2  = 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

Node  3  = 

0.25 

0.25 

0.25 

0.25 

0.25 

0.25 

0.25 

Node  4  = 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

Node  5  = 

0.35 

0.35 

0.35 

0.35 

0.35 

0.35 

0.35 

Link  Connection 

Sub  1  Sub  2  Sub  3  Sub  4  Sub  5  Sub  6 

Sub  7 

Used  Links 

Link  RHS 
Limits 

Nodel 

1 

1 

0 

0 

1 

1 

0 

1 

1 

Node  2 

1 

0 

1 

1 

0 

0 

1 

1 

1 

Node  3 

1 

0 

1 

0 

1 

1 

0 

1 

1 

Node  4 

0 

0 

1 

0 

0 

1 

1 

1 

1 

Node  5 

0 

1 

0 

1 

0 

0 

1 

1 

1 

Mutual  exclusivity 
Constraint 

1 

1 

1 

1 

1 

1 

#  of  Subs  Required  # 
of 

Chosen  Subnetworks 
1  2  2 

Link  Variable 

0 

0 

0 

0 

1 

0 

1 

Objective 

1 

1 

1 

1 

1 

1 

Total  Value 
of  Function 

1  2 
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A.4  Location  Calculations 


Simplifying  Assumptions: 

(1)  I  will  assume  that  the  travel  time  to  and  from  a  node  to  the  maintenance  depc 
equal.  This  means  thap  =  2. 

(2)  I  will  also  assume  a  constant  travel  speed  over  the  network,  v  =  55  miles  per 
hour. 

(3)  The  distance  between  nodes  is  assumed  to  be  miles,  and  is  defined  below  as  ve 

p:=2  v;=55  d:=(50  24  32  16  78  100  102) 


A,  =  0.45 

t  bar  =  0.505 
S  bar  =  1.01 

S2bar  =  1.837 

TRx=  1.263 
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^  bar  ■  bar 


S  bar  =0-808 


S2bar-T- 


\  Ni.i 


X  \  V 


S2k„  =  1.469 


X-S2bar 


TRx  =  0.924 


This  calculation  shows  the  best  location  to  be  at  node  3,  since  it  will  have  a  sma 
to  respon  versus  at  node  1. 

Subnetwork  2:  containing  nodes  2,4,  &  5. 


j:=1..3 


h:=  .1 


x  -Y, 

j=i 


X=0.55 


.-^2  ‘^1.7  ‘*1,3 


t  bar  =0.707 


8  bar  '“P'^bar 


Sbar  =  1-415 


S2bar  =3.363 


TRX- 


2-(l->.-Sbar) 


■•■Ibar 


TRx  =  4.877 


^  h,  d,  -  h  d  ,4-d  - 


■bar  =  >•*** 


8  bar  P'1  bar 


8  bar  =3.775 


82bar~ 


‘  x\  y  I  X,  L  V 


S2w  =  17.611 


TRx== 


2(>->-Sbar) 


+  ‘bar 


TRx =-2.612 
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Sj,aj-X  =  2.076  As  this  result  shows  a  negative  value  we  can  also 
check  the  requirement  SbarA-)<l.  Since  this 
value  is  greater  than  1  we  know  that  the  wait 
time  in  the  queue  is  infinite  which  clearly  shows 
that  on  this  network  you  would  not  want  to  put 
the  maintenance  depot  at  NODE  #4. 


NODE  5; 


*  ._*'2  ‘^1.3  , 


■■P’^bar 


•bar' 


S2bar--- 


^2. 

X 

i  V  1 

P‘(‘^1.3'*'^1.7) 


TR  Y  •“ 


X-S2 


bar 


+  ^bar 


‘bar  =0-549 

S  bar  *=1-098 
S2  bar  =4.563 

TO  x  =  3.715 


The  best  location  for  the  second  subnetwork  is  at  node  5,  then  node  2,  but  ne-' 
node  4  since  the  network  would  eventually  build  to  an  infinite  queue  and  henc« 
breakdown. 
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Appendix  B.  Network  Flow  Model 


B.l  Reliability  Calculations 

The  reliability  values  are  calculated  using  the  concepts  explained  in  Chapter  4  (based  i 
a  24-hour  period). 

The  minimum-time-to-respond  for  each  location  was  calculated  previously  in  Appendi 
pages  4  -  6.  The  values  for  each  subnetwork  are: 

Subnetwork  #1  Subnetwork  #2 

Loc3:=.924  LOC2-4.877 

Locj:=  1.263  L0C5-3.715 


The  flow  capacity  for  each  link  is  the  same:  Capacity  :=  50 


Solution  #1:  Using  Location  3  &  5 

I  Loc3\ 

Arcl:  -  ' 


Reliab  ^  :=  1  - 


•100 


Arc  2:  Reliab  2  •=  1 


24  / 

Reliab  ^  =  96.2 

Loc  3-hLoc  5\ 


100 


24 

Reliab  2  =  80.7 


/Reliab  j  ) 

Capac  1  :=  floor - Capacity 

^  \  100  I 

Capac  2  =  48 

/Reliab  2  ' 


Capac  2  :=floorl- 


\  100 
C^ac  2  =  40 


Capacity 


Arc  3: 


Reliab  o:=  1 - ^  -100 

'’I  24  i 


Reliab  3  =  84.5 


/Reliab  3  ' 

Capac  -3  := floor - Cracky 

^  \  100  / 

Capac  3  =  42 

/Reliab  4  ' 


Arc  4: 


Reliab  4:=  1- 


Loc3+Loc5\ 


24 


100 


Capac  4  := floor 


Reliab  4  =  80.7 


100 
Capac  4  =  40 


Cracky 
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Node  5: 


Node  6: 


Node  7: 


Solution  #2: 

Node  1: 


Node  2: 


Node  3: 


Node  4: 


Reliab5:=  1- 


Loc3+Loc5\ 


100 


Reliabg:=  1 


24  / 

Reliab  5  =  80.7 

Loc  3-t-Loc  5\ 
24  j 

Reliab  g  =  80.7 

I  ^5] 

Reliab 7  •=  1 1 - 24~) 

Reliab  7  =  84.5 

Using  Location  1  &  5 


100 


Reliab  j  •=  1 


Loc 


•100 


24  / 

Reliab  j  =  94.7 

/  Locit-Loc5\ 

Reuab2:=|l - - - J 

Reliab  2  =  79.3 
(  Loc5\ 

Reliab3:=ll--^|-100 
Reliab  3  =  84.5 

L0C1  +  L0C5I 


100 


Reliab  4  :=  1 1  - 


24 


•100 


Reliab  4  =  79.3 


/Reliab  5  ^ 

Capac  c  “floor - Capacity 

^  \  100  I 

Capac  5  =40 


/Reliab  i 


Capac  g  “floor 


100 
Capac  g  =  40 


•edacity 


/Reliab  7  ^ 

Capac  7  “floorl-^^^-Capacity^ 

Capac  7  =  42 


/Reliab  ^  1 

Capac  1  := floor - Capacity 

^  \  100  I 

Capac  1  =47 


Capac  2  '= floor 


Reliab  / 


100 
Capac  2  =  39 


•edacity 


/Reliab  3  1 

Capac  a  “floor - Capacity 

\  100  I 

Capac  3  =42 

/Reliab  4  ' 


Capac  4  :=  floor 


100 
Capac  4  =  39 


edacity 
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Node  5: 


Node  6: 


Node  7: 


Solution  #3: 
Node  1; 


Node  2: 


Node  3: 


Node  4: 


/  Loc  1  +  Loc  <i\ 
Reliab  5  :=  1 - — - ^  1  ■  100 

Reliab5=79.3 
Loc  j  -t-  Loc 


Reliab  ^  :=  1  - 

°  \  24 

Reliab  6  =  79.3 

/  ^5\ 

Reliab7:=ll--^l-100 
Reliab  7  =  84.5 


100 


Capac  5  ;= floor 


Reliab  5  \ 

- --Capacity 

100  / 


Capac  5  =  39 


Capac  g  ;= floor 


Reliab  < 


•Capacity 
100  / 


Capac  5  =  39 

/Reliab- 


Capac  7  := floor 


•Cracky 
100  / 


C^ac7  =  42 


Using  Location  3  &  2 


Loc  ■ 


Reliab  1  :=  1  - 


•100 


Reliab  2'=  1 


24  . 

Reliab  j  =  96.2 

Loc  3-1- Loc  2\ 


100 


24 

Reliab  2  =  75.8 


/Reliab  ^  1 

Capac  1  := floor - Capacity 

^  \  100  I 

C^ac  2  =  48 

/Reliab  2  ' 


Capac  2  ■= floor 


100 
Capac  2  =  37 


Capacity 


/  Loc2\ 

Reliab3;=  11- ^^1-100 
Reliab  3  =79.7 


LoCa-t-LoCot 

Reliab  4:=  1 - -100 

^  \  24  / 


Reliab  4  =  75.8 


/Reliab  3  \ 

Capac  -3  := floor - C^acity 

^  \  100  I 

Capac  3  =  39 

/Reliab  4  ' 


Capac  4  := floor 


100 
Capac  4  =  37 


Capacity 
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Node  5: 

Node  6: 

Node  7: 

Solution  #4: 
Node  1: 

Node  2: 

Node  3: 

Node  4: 


(LocT-t-LocM 

1 - £_ - £  .100 

Reliab5  =75.8 
Loc  3+Loc  2\ 


Reliab  a  :=  1  - 

°  \  24 

Reliab  6  =  75.8 

/  Loc2\ 

Reliab^  :=l  1 - ^^blOO 

Reliab  7  =  79.7 


100 


Using  Location  1  8l2 
I  Loci\ 


Reliab  i  !=  1 1  - 


•100 


24  . 

Reliab  1=94.7 

(Loc  1  +  Loc  2\ 

1 - 

24  / 

Reliab  2  =  74.4 

/  Loc2\ 

Reliab3:=ll--^|-100 
Reliab  3  =79.7 
Loc  1  +  Loc  2\ 


100 


Reliab4:=l  1- 


100 


24 


Reliab  4  =  74.4 


/Reliab  5 

Capac  <  ;= floor - Capacity 

^  \  100 

Capac  5  =  37 

/Reliab  g 

Capac  g  ;=floorl — -^^-Capacity 
Capac  6  =  37 


(Reliab  -j 

- edacity 

100 

C^ac7  =  39 


/Reliab  1 

Capac  1  ;= floor  I — ^^^-Capacity 
C^ac  1  =47 


(Reliab  2 

- Capacity 

100 

C^ac  2  =  37 


(Reliab  3 

- edacity 

100 

Capac  3  =  39 

/Reliab  4 

Capac  4  ;=floor - Cracky 

^  \  100 

Capac  4  =  37 
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Node  5: 


Node  6: 


Node  7: 


I 


Reliab  5  :=  1  - 


Loc  j  -I-  Loc  2\ 


100 


Reliab  g:= 


24  / 

Reliab  5  =  74.4 

'  Loc  j  +  Loc  2\ 

[  24  I 

Reliab  6  =  74.4 

I  Loc  < 


100 


Reliab7:=ll-  — 1- 


100 

Reliab  7  =  79.7 


/Reliab  5 

Capac  5  i=floorl — — ’C^acity 

Capac  5  =  37 

/Reliab  g 

Capac  1=  floor! - "C^acity 

^  \  100 

Capac  6  *  37 

/Reliab  7 

Capac  7  :=  floor - Capacity 

'  \  100 

Capac  7  =  39 
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B.2  SAS/OR  Case  Study  Network  #7 
OPTIONS  LINESIZE=72; 

TITLE  ’COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  1’; 

TITLE2  'MULTI-COMMODITY  TELECOMMUNICATION  NETWORK'; 
TITLES  'DELAY  OBJECTIVE  FUNCTION  INCLUDED  AS  CONSTRAINT; 
DATA  NODEO; 

INPUT  _NODE_  $  _SUPDEM_; 

CARDS; 

Nl_l  30 
N4_l  -30 
N2_2  30 
Nl_2  -30 
N3_3  30 
N5_3  -30 
N4_4  30 
N5_4  -30 
N5_5  30 
N2_5  -30 

DATAARCO; 

INPUT  _TAIL_  $  _HEAD_  $  _COST_  _CAPAC _ ^LO _ NAME_$6.; 

CARDS; 

Nl_l  N3_l  1  48  .  A131 
Nl_l  N4_l  1 40 .  A141 
Nl_l  N5_l  1 40 .  A151 
N3_l  N4_l  1 40 .  A341 
N3_l  N2_l  1  40  .  A321 
N2_l  N3_l  1  40  .  A231 
N5_l  N2_l  1  42  .  A521 
N2_l  N4_l  1  42 .  A241 
N2_2  N3_2  1  40  .  A232 
N2_2  N4_2  1  42  .  A242 
N2_2  N5_2  1  42  .  A252 
N3_2  N4_2  1  40  .  A342 
N3_2  Nl_2  1 48  .  A3 12 
N4_2  N3_2  1  40  .  A432 
N5_2  Nl_2  1 40 .  A512 
N4_2  Nl_2  1  40  .  A412 
N3_3  Nl_3  1 48  .  A313 
N3_3  N2_3  1  40 .  A323 
N3_3  N4_3  1  40  .  A343 
N4_3  N2_3  1  42 .  A423 
N4_3  Nl_3  1 40 .  A413 
Nl_3  N5_3  1  40 .  A153 
N2_3  N5_3  1  42  .  A253 
N4_4  Nl_4  1  40  .  A414 
N4_4  N2_4  1  42  .  A424 
N4_4  N3_4  1 40 .  A434 
N3_4  Nl_4 1 48  .  A3 14 
N3_4  N2_4 1 40 .  A324 
N2_4  N3_4 1 40 .  A234 
Nl_4  N3_4 1 48  .  A134 
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N2_4  N5_4 1 42  .  A254 
Nl_4  N5_4 1 40 .  A154 
N5_5  Nl_5  1 40 .  A515 
N5_5  N2_5  1  42 .  A525 
Nl_5  N3_5  1  48  .  A135 
Nl_5  N4_5  1 40  .  A145 
N3_5  N2_5  1 40 .  A325 
N3_5  N4_5  1 40 .  A345 
N4_5  N2_5  1  42  .  A425 
N4_5  N3_5  1 40 .  A435 
Nl_l  N6_l  100  30 .  LCl 
N6_l  N4_l  1 30 .  D1 
N2_2N6_2100  30.LC2 
N6_2  Nl_2  1 30 .  D2 
N3_3N6_3100  30.LC3 
N6_3  N5_3  1  30 .  D3 
N4_4  N6_4 100  30 .  LC4 
N6_2  N5_4  1  30 .  D4 
N5_5  N6_5  100  30 .  LC5 
N6_5  N2_5  1  30  .  D5 

DATA  CONDO; 

INPUT  _COLUMN_  $  _R0W1  $  _COEFl ; 

CARDS; 

A131  CONI  1 
A141  CONS  1 
A151  CON2  1 
A341  CON6  1 
A321  CON4  1 
A231  CON4  1 
A521  CON3  1 
A241  CON7  1 
A232CON41 
A242  CON7  1 
A252  CON3  1 
A342  CON6  1 
A312CON1  1 
A432  CON6  1 
A512CON21 
A412  CONS  1 
A313  CONI  1 
A323  CON4  1 
A343  CON6  1 
A423  CON7  1 
A413  CONS  1 
A1S3  CON2  1 
A2S3  CON3  1 
A414CONS1 
A424  CON7  1 
A434  CON6 1 
A314CON1  1 
A324  CON4  1 
A234  CON4  1 
A134  CONI  1 
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A254  C0N3  1 
A154CON21 
A515  C0N2  1 
A525  C0N3  1 
A135  CONI  1 
A145  CONS  1 
A325  CON4  1 
A345  CON6  1 
A425  CON7  1 
A435  CON6  1 
_TYPE_CONl  -1 
_TYPE_CON2-l 
_TYPE_CON3-l 
_TYPE_CON4-l 
_TYPE_CON5-l 
_TYPE_CON6-l 
_TYPE_CON7-l 
_RHS_CON148 
_RHS_CON240 
_RHS_CON3  42 
_RHS_CON440 
_RHS_CON5  40 
_RHS_CON640 
_RHS_CON742 

PROCNETFLOW 

SCDATA 

NODEDATA=NODEO 

ARCDATA=ARCO 

CONDATA=CONDO 

CONOUT=SOLUnON; 

RUN; 

PROC  PRINT  DATA=SOLUnON; 
SUM_FCOST_; 
SUM_DEMAND_; 

RUN; 

ENDSAS; 
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B.3  SAS/OR  Case  Study  #1  Solution 

COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  1  1 

MULTI -COMMODITY  TELECOMMUNICATION  NETWORK 
DELAY  OBJECTIVE  FUNCTION  INCLUDED  AS  CONSTRAINT 

00:52  Wednesday,  January  25,  1995 
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38  Nl_l  N5_l  1  40 

39  N2_2  N5_2  1  42 

40  Nl_3  N5_3  1  40 

41  N2_3  N5_3  1  42 

42  N6_3  N5_3  1  30 

43  N2_4  N5_4  1  42 

44  Nl_4  N5_4  1  40 

45  N6_2  N5_4  1  30 

46  Nl_l  N6_l  100  30 
47  N2_2  N6_2  100  30  0 

48  N3_3  N6_3  100  30 

49  N4_4  N6_4  100  30 

50  N5_5  N6_5  100  30 
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BA  Delay  Constraint  Development 


The  development  of  the  network  delay  constraint  from  the  objective  function  for  network  delay 
required  the  understanding  of  what  each  element  of  the  original  work  by  Kleinrock  entailed.  Tl 
important  thing  to  realize  was  the  meaning  and  units  associated  with  each  variable  or  constant 
the  formula.  The  formula  for  approximating  delay  within  an  individual  link  is  presented  below: 

IS’' " 

Delay^l  peOqeD 
link  Y  h-Cy 

where:  y  =  Total  network  throughput  (Messages/Time  Unit) 

=  Average  call  length  (Time  Unit) 

^  &  Link  capacity  (Messages/Time  Unit) 

X  Number  of  messages  (Messages) 

Link  =  Number  of  links  in  network 

The  time  units  involved  in  the  development  of  this  formulation  are  not  that  significant  as  lor 
you  are  consistent  throughout.  I  used  seconds  for  this  development  since  the  originial  LOSAs 
been  written  with  a  maximum  delay  of  .1  seconds  per  message. 

I  made  the  following  assumptions:  y  =  150  Messages /Second 

H  =  1  Second 

1-3  =48  C 


1- 5  =  V- 

2- 3  =40  C 

2.,  =  42  C 

3- 4  =  40  C 

2-5  =42  C 


Additionally,  I  will  create  three  points  for  consideration  in  the  efficient  frontier.  These  i 
depend  upon  the  delay  factor.  The  three  delay  factors  are:  Delay  <  .05,  .10,  and  .20 


Sinplifying  the  previous  equation  into  the  constraint  form  yields: 


II  x.-'= 

peOqeD 


Delay  y  m-Cu 


link 


Since  there  are  only  three  different  capacities  in  the  list  of  links,  I  only  solve  for  the  tl 
Y  :=  150  |i  1=  1  link  1=7  C  ‘==48  C24  J=42  C  ^41= 40 
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Solution  1:  (Delay  <  .01)  Delay  ;=  .01 


Arc  1-3  (C=48): 


SS 

peOqeD 


EE 

peOqeD 


y-Delay-ji-C  j3 
Unk 


=  10,286 


Arc  1-4  (C=40) : 


X 


p»q< 
u  ” 


y*Delayji*Cj4 

Unk 


peOqeD 


EE 

peOqeD 


yr)elayp*Ci4 
1 - : - i3  =  8.571 


Unk 


Arc  2-4  (C=42): 


EE 

peOqeD 


y-Delayp-C24 


Unk 


yDelaypC24 

Unk 


EE 

peOqeD 

The  resulting  network  delay  constraints  are  now  more  restrictive  than  the  capacity  const 
and  must  be  substituted  for  the  capacity  constraints. 


Solution  2:  (Delay  <  .05)  Delay- .05 


Arc  1-3  (C=48): 


ZjZj  ^  Unk 

peOqeD 


EE 

peOqeD 


y-Delay-p-C  ^ 


=51.429 


Unk 
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Arc  1-4  {C=40) : 


peOqeD 

peOqeD 


y-Delay  C  j4 


=  42.857 


Link 


Arc  2-4  (C=42) : 


W  V  p.q^ir  Delay^C24 

2^Zj  “  Link 

peOqeD 


YDelaynC24 


=  45 


Link 


peOqeD 

This  solution  does  not  create  a  more  restrictive  delay  constraint  set  and  is  therefore  i 
The  same  solution  set  that  was  used  in  Step  2,2  is  used. 


Solution  3:  (Delay  <  *10)  Delay :=.io 


Arc  1-3  (C=48): 


X 


p.q< 
u  ^ 


y-Delay  ^  €13 

Ui* 


peOqeD 


SE 

peOqeD 


Y*Delay*n-C|3 


=  102.857 


Link 


Arc  1-4  (C=40): 


EE- 

peOqeD 


p.q^ 


y  Delay-^i-C  j4 
Link 


EE 

peOqeD 


yDelay-^i  C  j4 


=  85.714 


Link 
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Arc  2-4  (C=42): 


22 

peOqeD 


Link 


yDelayp-C24 

Link 


=  90 


peOqeD 

This  solution  does  not  create  a  more  restrictive  delay  constraint  set  and  is  therefore  red 
The  same  solution  set  that  was  used  in  Step  2.2  is  used. 
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B.5  SAS/OR  Case  Study  Network  #1  (Delay  <  .01) 


OPTIONS  LINESIZE=72; 

TITLE  ‘ COMMUNICATIONS  NETWORK  -  CASE  1 :  SOLUTION  2 ' ; 

TITLE2  'MULTI -COMMODITY  TELECOMMUNICATION  NETWORK'; 

TITLES  'DELAY  OBJECTIVE  FUNCTION  INCLUDED  AS  CONSTRAINT'; 
DATA  NODEO; 

INPUT  _NODE_  $  _SUPDEM_; 

CARDS; 

Nl_l  30 
N4_l  -30 
N2_2  30 
Nl_2  -30 
N3_3  30 
N5_3  -30 
N4_4  30 
N5_4  -30 
N5_5  30 
N2_5  -30 
/ 

DATA  ARCO • 

INPUT  _TAIL_  $  _HEAD_  $  _COST _ CAP  AC _ LO_  _NAME_$6. 

CARDS; 

Nl_l  N3_l  1  10  .  A131 
Nl_l  N4_l  1  8  .  A141 

Nl_l  N5_l  1  8  .  A151 

N3_l  N4_l  1  8  .  A3 41 

N3_l  N2_l  1  8  .  A3 21 

N2_l  N3_l  1  8  .  A231 

N5_l  N2_l  1  9  .  A521 

N2_l  N4_l  1  9  .  A241 

N2_2  N3_2  1  8  .  A232 

N2_2  N4_2  1  9  .  A242 

N2_2  N5_2  1  9  .  A252 

N3_2  N4_2  1  8  .  A3 42 

N3_2  Nl_2  1  10  .  A3 12 
N4_2  N3_2  1  8  .  A432 

N5_2  Nl_2  1  8  .  A512 

N4_2  Nl_2  1  8  .  A412 

N3_3  Nl_3  1  10  .  A3 13 
N3_3  N2_3  1  8  .  A3 23 

N3_3  N4_3  1  8  .  A3 43 

N4_3  N2_3  1  9  .  A423 

N4_3  Nl_3  1  8  .  A413 

Nl_3  N5_3  1  8  .  A153 

N2_3  N5_3  1  9  .  A253 

N4_4  Nl_4  1  8  .  A414 

N4_4  N2_4  1  9  .  A424 

N4_4  N3_4  1  8  .  A434 

N3_4  Nl_4  1  10  .  A314 
N3_4  N2_4  1  8  .  A3 2 4 

N2_4  N3_4  1  8  .  A234 

Nl_4  N3_4  1  10  .  A134 
N2_4  N5_4  1  9  .  A254 

Nl_4  N5_4  1  8  .  A154 

N5_5  Nl_5  1  8  ,  A515 

N5_5  N2_5  1  9  .  A525 

Nl_5  N3_5  1  10  .  A135 
Nl_5  N4_5  1  8  .  A145 

N3_5  N2_5  1  8  .  A3 2 5 

N3_5  N4_5  1  8  .  A3 4 5 

N4_5  N2_5  1  9  .  A425 

N4_5  N3_5  1  8  .  A435 
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Nl. 

1 

N6_l 

100  30 

.  LCl 

N6. 

1 

N4_l 

1  30  . 

D1 

N2. 

2 

N6_2 

100  30 

.  LC2 

N6. 

2 

Nl_2 

1  30  . 

D2 

N3. 

3 

N6_3 

100  30 

.  LC3 

N6. 

3 

NS_3 

1  30  . 

D3 

N4. 

4 

N6  4 

100  30 

.  LC4 

N6. 

4 

NS_4 

1  30  . 

D4 

NS. 

5 

N6  S 

100  30 

.  LCS 

N6. 

5 

N2  S 

1  30  . 

DS 

DATA  CONDO; 

INPUT  _COLUMN_  $  _ROWl  $  _COEFl  ; 

CARDS; 

A131  CONI  1 
A141  CON5  1 
A151  CON2  1 
A3 41  CON6  1 
A3  21  CON4  1 
A231  CON4  1 
A521  CON3  1 
A241  CON7  1 
A232  CON4  1 
A242  CON7  1 
A252  CON3  1 
A3 4 2  CON6  1 
A3 12  CONI  1 
A432  CON6  1 
A512  CON2  1 
A412  CONS  1 
A3 13  CONI  1 
A3 23  CON4  1 
A3  4 3  CON6  1 
A423  CON7  1 
A413  CONS  1 
A1S3  CON2  1 
A2S3  CON3  1 
A414  CONS  1 
A424  CON7  1 
A434  CON6  1 
A3 14  CONI  1 
A3 2 4  CON4  1 
A234  CON4  1 
A134  CONI  1 
A2S4  CON3  1 
A1S4  CON2  1 
AS IS  CON2  1 
AS2S  CON3  1 
A13S  CONI  1 
A14S  CONS  1 
A32S  CON4  1 
A34S  CON6  1 
A42S  CON7  1 
A43S  CON6  1 
_TYPE_  CONI  -1 
_TYPE_  CON2  -1 
_TYPE_  CON3  -1 
_TYPE_  CON4  -1 
_TYPE_  CONS  -1 
_TYPE_  CON6  -1 
_TYPE_  CON7  -1 
_RHS_  CONI  10 
_RHS_  CON2  8 
_RHS_  CON3  9 
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_RHS_  C0N4  8 
_RHS_  C0N5  8 
_RHS_  C0N6  8 
_RHS_  C0N7  9 

PROC  NETFLOW 
SCDATA 

NODEDATA=NODEO 
ARCDATA=ARCO 
CONDATA=CONDO 
CONOUT= SOLUTION ; 

RUN; 

PROC  PRINT  DATA=SOLUTION 
SUM  _FCOST_; 

SUM  _DEMAND_; 

RUN; 

ENDSAS; 
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SAS/OR  Case  Study  (Delay  <  .01)  Solution 


COMMUNICATIONS  NETWORK  -  CASE  1;  SOLUTION  2  1 

MULTI -COMMODITY  TELECOMMUNICATION  NETWORK 
DELAY  OBJECTIVE  FUNCTION  INCLUDED  AS  CONSTRAINT 

17:28  Thursday,  February  2,  1995 
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Appendix  C.  Case  Study  Win-Win  Example 


C.  1  SAS/OR  Case  Study  Network  #2 


OPTIONS  LINESIZE=72; 

TITLE  'COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  2’; 

TITLE2  'MULTl-COMMODnY  TELECOMMUNICATION  NETWORK’; 
TITLES  DELAY  OBJECTIVE  INCLUDED  AS  CONSTRAINT:  DELAY  =  .10'; 
DATANODEO; 

INPUT  _NODE_  $  _SUPDEM_; 

CARDS; 

Nl_l 30 
N4_l  -30 
N2_2  30 
Nl_2  -30 
N3_3  30 
N5_3  -30 
N4_4  30 
N5_4  -30 
N5_5  30 
N2_5  -30 

DATAARCO; 

INPUT  _TAIL_  $  _HEAD_  $  _COST_  _CAPAC_  _LO_  _NAME_$6.; 
CARDS; 

Nl_l  N3_l  1  47  .  A131 
Nl_l  N4_l  1  39  .  A141 
Nl_l  N5_l  1  39  .  A151 
N3_l  N4_l  1  39  .  A341 
N3_l  N2_l  1  39  .  A321 
N2_l  N3_l  1  39  .  A231 
N5_l  N2_l  1  42  .  A521 
N2_l  N4_l  1  42  .  A241 
N2_2  N3_2 1  39  .  A232 
N2_2  N4_2  1  42  .  A242 
N2_2  N5_2  1 42  .  A252 
N3_2  N4_2 1  39  .  A342 
N3_2  Nl_2 1  47  .  A3 12 
N4_2  N3_2  1  39  .  A432 
N5_2  Nl_2  1  39  .  A512 
N4_2  Nl_2  1  39  .  A412 
N3_3  Nl_3  1 47  .  A313 
N3_3  N2_3  1  39  .  A323 
N3_3  N4_3  1  39  .  A343 
N4_3  N2_3  1  42  .  A423 
N4_3  Nl_3  1  39  .  A413 
Nl_3  N5_3  1  39  .  A153 
N2_3  N5_3  1 42  .  A253 
N4_4  Nl_4  1  39  .  A414 
N4_4  N2_4  1  42 .  A424 
N4_4  N3_4 1  39  .  A434 
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N3_4  Nl_4  1 47  .  A3 14 
N3_4  N2_4  1  39  .  A324 
N2_4  N3_4 1  39  .  A234 
N1_4N3_4147.A134 
N2_4  N5_4 1  42 .  A254 
Nl_4  N5_4 1  39  .  A154 
N5_5  Nl_5  1  39  .  A515 
N5_5  N2_5  1 42 .  A525 
Nl_5  N3_5  1 47  .  A135 
Nl_5  N4_5  1  39  .  AMS 
N3_5  N2_5  1  39  .  A325 
N3_5  N4_5  1  39  .  A345 
N4_5  N2_5  1 42 .  A425 
N4_5  N3_5  1  39  .  A435 
Nl_l  N6_l  100  30 .  LCl 
N6_l  N4_l  1  30 .  D1 
N2_2  N6_2 100  30 .  LC2 
N6_2  Nl_2  1  30  .  D2 
N3_3  N6_3  100  30  .  LC3 
N6_3  N5_3  1  30 .  D3 
N4_4  N6_4  100  30  .  LC4 
N6_2  N5_4  1  30  .  D4 
N5_5  N6_5  100  30 .  LC5 
N6_5  N2_5  1  30 .  D5 

DATA  CONDO: 

INPUT  _COLUMN_  $  _R0W1  $  _COEFl ; 

CARDS; 

A131  CONI  1 
AMI  CONS  1 
AlSl  CON2  1 
A341  CON6  1 
A321  CON4  1 
A231  CON4  1 
AS21  CON3  1 
A241  CON7  1 
A232CON41 
A242CON71 
A2S2  CON3  1 
A342CON61 
A312CON1  1 
A432  CON6  1 
AS12  CON2  1 
A412CONS1 
A313  CONI  1 
A323  CON4  1 
A343  CON6  1 
A423  CON7  1 
A413  CONS  1 
A1S3  CON2  1 
A2S3  CON3  1 
A4MCONS  1 
A424  CON7  1 
A434  CON6  1 
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A314CON1  1 
A324CON41 
A234CON41 
A134CON1  1 
A254  C0N3  1 
A154  C0N2  1 
A515  C0N2  1 
A525  C0N3  1 
A135  CONI  1 
A145  CONS  1 
A325  CON4  1 
A345  CON6  1 
A425  CON7  1 
A435  CON6  1 
_TYPE_CONl  -1 
_TYPE_CON2-l 
_TYPE_CON3-l 
_TYPE_CON4-l 
_TYPE_CON5-l 
_TYPE_CON6-l 
_TYPE_CON7-l 
_RHS_CON147 
_RHS_CON2  39 
_RHS_CON342 
_RHS_CON4  39 
_RHS_CON5  39 
_RHS_CON6  39 
_RHS_CON742 

PROCNETFLOW 

SCDATA 

NODEDATA=NODEO 

ARCDATA=ARCO 

CONDATA=CONDO 

CONOUT=SOLUnON; 

RUN; 

PROC  PRINT  DATA=SOLUnON; 
SUM_FCOST_; 
SUM_DEMAND_; 

RUN; 

ENDSAS; 
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C.2  SAS/OR  Case  Study  Network 


OPTIONS  LINESIZE=72; 

TITLE  'COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  3'; 

TnLE2  'MULTI-COMMODITY  TELECOMMUNICATION  NETWORK'; 
TITLES  'DELAY  OBJECTIVE  INCLUDED  AS  CONSTRAINT:  DELAY  =  .10'; 
DATANODEO; 

INPUT  _NODE_  $  _SUPDEM_; 

CARDS; 

Nl_l 30 
N4_l  -30 
N2_2  30 
Nl_2  -30 
N3_3  30 
N5_3  -30 
N4_4  30 
N5_4  -30 
N5_5  30 
N2_5  -30 

DATA  ARCO; 

INPUT  _TAIL_  $  _HEAD_  $  _COST_  _CAPAC_  _LO_  _NAME_$6.; 
CARDS; 

Nl_l  N3_l  1  48  .  A131 
Nl_l  N4_l  1  37  .  A141 
Nl_l  N5_l  1  37  .  A151 
N3_l  N4_l  1  37  .  A341 
N3_l  N2_l  1  37  .  A321 
N2_l  N3_l  1  37  .  A231 
N5_l  N2_l  1  39  .  A521 
N2_l  N4_l  1  39  .  A241 
N2_2  N3_2  1  37  .  A232 
N2_2  N4_2  1  39  .  A242 
N2_2  N5_2  1  39  .  A252 
N3_2  N4_2  1  37  .  A342 
N3_2N1_2148.A312 
N4_2  N3_2 1  37  .  A432 
N5_2  Nl_2  1  37  .  A512 
N4_2  Nl_2 1  37  .  A412 
N3_3  Nl_3  1 48  .  A313 
N3_3  N2_3  1  37  .  A323 
N3_3  N4_3  1  37  .  A343 
N4_3  N2_3  1  39  .  A423 
N4_3  Nl_3  1  37  .  A413 
Nl_3  N5_3  1  37  .  A153 
N2_3  N5_3  1  39  .  A253 
N4_4  Nl_4 1  37  .  A414 
N4_4  N2_4  1  39  .  A424 
N4_4  N3_4  1  37  .  A434 
N3_4  Nl_4 1 48  .  A314 
N3_4  N2_4 1  37  .  A324 
N2_4N3_4137.A234 
Nl_4  N3_4  1  48  .  A134 
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N2_4  N5_4  1  39  .  A254 
Nl_4  N5_4 1  37  .  A154 
N5_5  Nl_5  1  37  .  A515 
N5_5  N2_5  1  39  .  A525 
Nl_5  N3_5  1  48  .  A135 
Nl_5  N4_5  1  37  .  AU5 
N3_5  N2_5  1  37  .  A325 
N3_5  N4_5  1  37  .  A345 
N4_5  N2_5  1  39  .  A425 
N4_5  N3_5  1  37  .  A435 
Nl_l  N6_l  100  30 .  LCl 
N6_l  N4_l  1  30 .  D1 
N2_2  N6_2 100  30 .  LC2 
N6_2  Nl_2  1  30 .  D2 
N3_3  N6_3  100  30 .  LC3 
N6_3  N5_3  1  30 .  D3 
N4_4  N6_4  100  30 .  LC4 
N6_2N5_4130.D4 
N5_5  N6_5  100  30 .  LC5 
N6_5  N2_5  1  30 .  D5 

DATA  CONDO; 

INPUT  _COLUMN_  $  _R0W1  $  _C0EF1 ; 

CARDS; 

A131  CONI  1 
A141  CONS  1 
A151  CON2  1 
A341  CON6  1 
A321  CON4  1 
A231  CON4  1 
A521  CON3  1 
A241  CON7  1 
A232CON41 
A242  CON7  1 
A252  CON3  1 
A342  CON6  1 
A312  CONI  1 
A432  CON6  1 
A512  CON2 1 
A412  CONS  1 
A313  CONI  1 
A323  CON4  1 
A343  CON6 1 
A423  CON7  1 
A413  CONS  1 
A1S3  CON2  1 
A2S3  CON3  1 
A414  CONS  1 
A424  CON7  1 
A434CON61 
A314  CONI  1 
A324  CON4  1 
A234  CON4  1 
A134  CONI  1 
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A254  C0N3  1 
A154  C0N2  1 
A515  C0N2  1 
A525  C0N3  1 
A135  CONI  1 
A145  CONS  1 
A325  CON4  1 
A345  CON6  1 
A425  CON7  1 
A435  CON6  1 
_TYPE_CONl  -1 
_TYPE_CON2-l 
_TYPE_CON3-l 
_TYPE_CON4-l 
_TYPE_CON5-l 
_TYPE_CON6-l 
_TYPE_CON7  -1 
_RHS_CON148 
_RHS_CON2  37 
_RHS_CON3  39 
_RHS_CON4  37 
_RHS_CON5  37 
_RHS_CON6  37 
_RHS_CON7  39 

PROC  NETFLOW 
SCDATA 

NODEDATA=NODEO 

ARCDATA=ARCO 

CONDATA=CONDO 

CONOUT=SOLUnON; 

RUN; 

PROC  PRINT  DATA=SOLUnON; 
SUM_FCOST_; 
SUM_DEMAND_; 

RUN; 

ENDSAS; 
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C.3  SAS/OR  Case  Study  Network  #4 


OPTIONS  LINESIZE=72; 

TITLE  'COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  4'; 

■nTLE2  'MULTI-COMMODITY  TELECOMMUNICATION  NETWORK'; 
TITLES  DELAY  OBJECTIVE  INCLUDED  AS  CONSTRAINT:  DELAY  =  .01'; 
DATANODEO; 

INPUT  _NODE_  $  _SUPDEM_; 

CARDS; 

Nl_l 30 
N4_l  -30 
N2_2  30 
Nl_2  -30 
N3_3  30 
N5_3  -30 
N4_4  30 
N5_4  -30 
N5_5  30 
N2_5  -30 

DATA  ARCO; 

INPUT  _TAIL_  $  _HEAD_  $  _COST _ ^CAPAC_  _LO_  _NAME_$6.; 

CARDS; 

Nl_l  N3_l  1  47  .  A131 
Nl_l  N4_l  1  37  .  A141 
Nl_l  N5_l  1  37  .  A151 
N3_l  N4_l  1  37  .  A341 
N3_l  N2_l  1  37  .  A321 
N2_l  N3_l  1  37  .  A231 
N5_l  N2_l  1  39  .  A521 
N2_l  N4_l  1  39  .  A241 
N2_2N3_2137.A232 
N2_2  N4_2 1  39  .  A242 
N2_2  N5_2 1  39  .  A252 
N3_2  N4_2 1  37  .  A342 
N3_2  Nl_2 1 47  .  A312 
N4_2  N3_2  1  37  .  A432 
N5_2  Nl_2 1  37  .  A512 
N4_2  Nl_2  1  37  .  A412 
N3_3  Nl_3  1  47  .  A313 
N3_3  N2_3  1  37  .  A323 
N3_3  N4_3  1  37  .  A343 
N4_3  N2_3  1  39  .  A423 
N4_3  Nl_3  1  37  .  A413 
Nl_3  N5_3  1  37  .  A153 
N2_3  N5_3  1  39  .  A253 
N4_4  Nl_4  1  37  .  A414 
N4_4  N2_4 1  39  .  A424 
N4_4  N3_4  1  37  .  A434 
N3_4  Nl_4  1 47  .  A3 14 
N3_4N2_4137.A324 
N2_4  N3_4  1  37  .  A234 
Nl_4  N3_4 1  47  .  A134 
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N2_4  N5_4 1  39  .  A254 
Nl_4  N5_4 1  37  .  A154 
N5_5  Nl_5  1  37  .  A515 
N5_5  N2_5  1  39  .  A525 
Nl_5  N3_5  1 47  .  A135 
Nl_5  N4_5  1  37  .  A145 
N3_5  N2_5  1  37  .  A325 
N3_5  N4_5  1  37  .  A345 
N4_5  N2_5  1  39  .  A425 
N4_5  N3_5  1  37  .  A435 
N1_1N6_1 100  30.LC1 
N6_l  N4_l  1  30  .  D1 
N2_2  N6_2  100  30  .  LC2 
N6_2  Nl_2  1  30 .  D2 
N3_3  N6_3  100  30 .  LC3 
N6_3  N5_3  1  30 .  D3 
N4_4  N6_4 100  30 .  LC4 
N6_2  N5_4  1  30 .  D4 
N5_5  N6_5  100  30  .  LC5 
N6_5  N2_5  1  30  .  D5 

DATA  CONDO; 

INPUT  _COLUMN_  $  _R0W1  $  _C0EF1 ; 

CARDS; 

A131  CONI  1 
A141  CONS  1 
A151  CON2  1 
A341  CON6  1 
A321  CON4  1 
A231  CON4  1 
A521  CON3  1 
A241  CON7  1 
A232  CON4  1 
A242CON71 
A252  CON3  1 
A342  CON6  1 
A312  CONI  1 
A432  CON6  1 
AS  12  CON2  1 
A412  CONS  1 
A313  CONI  1 
A323  CON4  1 
A343  CON6  1 
A423  CON7  1 
A413  CONS  1 
A1S3  CON2  1 
A2S3  CON3  1 
A414  CONS  1 
A424  CON7  1 
A434  CON6  1 
A3 14  CONI  1 
A324CON41 
A234CON41 
A134  CONI  1 


C-8 


A254  C0N3  1 
A154  C0N2  1 
A515  C0N2  1 
A525  C0N3  1 
A135  CONI  1 
AMS  CONS  1 
A32S  CON4  1 
A34S  CON6  1 
A42S  CON7  1 
A43S  CON6  1 
_TYPE_CONl  -1 
_TYPE_CON2-l 
_TYPE_CON3-l 
_TYPE_CON4-l 
_TYPE_CONS-l 
_TYPE_CON6-l 
_TYPE_CON7-l 
_RHS_CON147 
_RHS_CON2  37 
_RHS_CON3  39 
_RHS_CON4  37 
_RHS_CONS37 
_RHS_CON6  37 
_RHS_CON7  39 

PROCNETFLOW 

SCDATA 

NODEDATA=NODEO 

ARCDATA=ARCO 

CONDATA=CONDO 

CONOUT=SOLUnON; 

RUN; 

PROC  PRINT  DATA=SOLUnON; 
SUM_FCOST_; 
SUM_DEMAND_; 

RUN; 

ENDSAS; 


CA  SAS/OR  Case  Study  #2  Solution 


COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  2  1 

MULTI -COMMODITY  TELECOMMUNICATION  NETWORK 
DELAY  OBJECTIVE  INCLUDED  AS  CONSTRAINT:  DELAY  =  .10 

17:35  Thursday,  February  2,  1995 
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SAS/OR  Case  Study  #3  Solution 


COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  3  1 

MULTI -COMMODITY  TELECOMMUNICATION  NETWORK 
DELAY  OBJECTIVE  INCLUDED  AS  CONSTRAINT:  DELAY  =  .10 

17:36  Thursday,  February  2,  1995 
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SAS/OR  Case  Study  M  Solution 


COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  4  1 

MULTI -COMMODITY  TELECOMMUNICATION  NETWORK 
DELAY  OBJECTIVE  INCLUDED  AS  CONSTRAINT:  DELAY  =  .01 

17:53  Thursday,  February  2,  1995 
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Appendix  D.  Case  Study:  Extension 


The  development  of  the  network  delay  constraints  was  previously  accomplished 
in  Appendix  B.4.  The  development  was  for  the  general  case  and  then  showed  the  specific 
calculations  for  maintenance  depots  located  at  nodes  3  and  5.  The  next  three  sections  will 
present  the  calculations  for  delay  for  the  other  three  possible  locations. 


D.  1  Delay  Constraints  @  Location  1  &  5 


I  will  continue  to  use  three  points  for  consideration  in  the  efficient  frontier.  These  points 
be  the  same  delay  factors  from  previously:  Delay  <  .01,  .05,  and  .10 


The  constraint  form  is: 


peOqsD 


V 


Delayy*pC^ 


Link 


Since  there  are  only  three  different  capacities  in  the  list  of  links,  I  only  solve  for  the  three 
y:=150  p:-l  Link;=7  €24=42  Cj4:=39 


Solution  1:  (Delay <. 01)  Delay  =.oi 


Arc  1-3  (C=48): 


X 


p.q< 

u 


y- Delay*  |i*C 
Link 


peOqeD 


ZZ 

peOqeD 


y -Delay*  p*C 

- -  =  10.071 

Link 


Arc  1-4  (C=40): 


V  V  X 

“  Link 

peOqsD 


ZZ’*-"’-* 

peOqeD 


y -Delay- p‘C  14 

- ^ - ^=8.357 

Link 


D-1 


Arc  2-4  (C=42): 


peOqsD 


p,q<. 


Y  •  Delay- p’C  24 
Link 


Y -Delay- ^-C  24 
Link 


peOqeD 

The  resulting  network  delay  constraints  are  now  more  restrictive  than  the  capa 
constraints  and  must  be  substituted  for  the  capacity  constraints. 


Solution  2:  (Delay  <  .05) 


Arc  1-3  (C=48):  XiS 


Delay  -  .05 

Y-Delay-p-C  ^3 


peOqeD 


Link 


EE 

peOqeD 


51 


Y*Delay*p-C  13 


=  50.357 


Link 


Arcl-4(C=40): 

psOqsD 

EE 

peOqeD 


Y-Delay-p-C  ^4  Y*C)elay-p*C  ^4 


Link 


Link 


=  41.786 


Arc  2-4  (C=42): 


Y-Delay^-C24 

Za  2^  ^  Link 

peOqsD 


Y -Delay- p-C  24 

- =3=45 


Link 


EE 

peOqsD 

This  solution  does  not  create  a  more  restrictive  delay  constraint  set  and  is  therefore  redim 
The  seime  solution  set  that  was  used  in  Step  2.2  is  used. 
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Solution  3:  (Delay  <  .10) 


Delay  :=  .10 


Arc  1-3  (C=48): 


Lh^'‘  - 

peOqeD 


si: 

peOqeD 


Y'Delay-p-C 

- =100.714 

Link 


Arc  M  (C=40): 


2.2.’'-  - — ns — 

pEOqeD 


SS 

peOqsD 


y•Delay•^•C  14 

- =83.571 

Link 


Arc  2-4  (C=42):  SS- 

peOqeD 

ss- 

peOqeD 

This  solution  does  not  create  a  more  restrictive  delay  constraint  set  and  is  therefor 
redundant.  The  same  solution  set  that  was  used  in  Step  2.2  is  used. 


p^^yDelay^-C24 
^  Link 


p.q_ 


feQO 


y  •  Delay -n-C  24 
Link 


=  90 
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D.2  Delay  Constraints  @  Location  3  &  2 


I  will  continue  to  use  three  points  for  consideration  in  the  efficient  frontier.  These  points 
be  the  same  delay  factors  from  previously:  Delay  <  .01,  .05,  and  .10 


The  constraint  form  is: 


X.P’‘'= 


Delay  y  ii  Cy 
Link 


peOqeD 

Since  there  are  only  three  different  capacities  in  the  list  of  links,  I  only  solve  for  the  three 
y;=150  Link:  =  7  C24'  =  39  Cj4:=37 


Solution  1:  (Delay  <  .01)  Delay  =  .oi 


Arc  1-3  (C=48): 


2.2. -u 

psOqeD 


Link 


peOqeD 


y -Delay*  p-C  io 

- —  - 10.286 

Link 


Arc  1-4  (C=40): 


p  q^Y-Delayii-C|4 


2.2. -u 

peOqeD 


Link 


ZZ 

psOqeD 


y -Delay*  p*C  ^4 


Link 


7.929 


Arc  2-4  (C=42): 


V 


yDelay-p*C24 
Link 


peOqsD 


y -Delay*  p*C  24 
Link 


8.357 


peOqeD 

The  resulting  network  delay  constraints  are  now  more  restrictive  than  the  capacity 
constraints  and  must  be  substituted  for  the  capacity  constraints. 
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Solution  2:  (Delay  <  .05) 


Arc  1-3  (C=48): 


Delay  :  =  .05 

y-DelayiaC  13 


P,q<_ 


Link 


peOqeD 

peOqeD 


y  Delay-fi-C  ^3 


=  51.429 


Link 


Arc  1-4  (C=40): 


ZZ  Xu"'" 

peOqsD 

ZZ  Xu"”- 

pEOqeD 


y  Delay  |a  Cj4  y  Delay  n  Cj4 


Link 


39 


=  39.643 


Link 


Arc  2-4  (C=42): 


Z-I  z_(  “  Link 


peOqeD 


y-Delay|iC24 


=  41.786 


Link 


ZZ  Xu"'«' 

peOqeD 

This  solution  does  not  create  a  more  restrictive  delay  constraint  set  and  is  therefore  redun 
The  same  solution  set  that  was  used  in  Step  2.2  is  used. 
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Solution  3:  (Delay  <  .10) 


Delay  :  =  .10 


Arc  1-3  (C=48): 


peOqeD 


X 


p^^Y-Delay^-Ci3 

Link 


XT. 

peOqeD 


y*Delay-p-C  ^3 


Link 


102.857 


Arc  1-4  (C=40): 


p  ^  Y-Delayn-Ci4 

2-1 2-t  “  Link 

psOqeD 


peOqsD 


y-Delay-p-Ci4 

- 79.286 

Link 


Arc  2-4  (C=42): 


v-v-  ^  p.q.Y-Delayn-C24 

2_.2_.^u  -  Link 

peOqeD 


y-Delay-p-Cod 

- 83.571 

Link 


peOqeD 

This  solution  does  not  create  a  more  restrictive  delay  constraint  set  and  is  therefor 
redvmdant.  The  same  solution  set  that  was  used  in  Step  2.2  is  used. 
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D.3  Delay  Constraints  @  Location  1  &  2 


I  will  continue  to  use  three  points  for  consideration  in  the  efficient  frontier.  These  points 
be  the  same  delay  factors  from  previously:  Delay  <  .01,  .05,  and  .10 


The  constraint  form  is: 


-  Link 

psOqeD 


Since  there  are  only  three  different  capacities  in  the  list  of  links,  I  only  solve  for  the  three 
y:=150  (1=1  Link-7  0^3=47  C24  =39  CJ4-37 


Solution  1:  (Delay  <  .01) 


Arc  1-3  (C-48):  ’‘u’  '- 


Delay  -  .01 

y-Delay  p  C 


Link 


peOqeD 


peOqaD 


10 


y-Delay-p-C 

Link 


=  10.071 


Arcl-4(C=40): 

peOqeD 

psOqeD 


y-Delayp-C  ^4  y*Delayp*C  ^4 


Link 


7329 


Link 


Arc  2-4  (C=42): 


X 


p,q<, 


y  Delay  p'C  24 


Link 


peOqeD 


y  Delay  p  C  24 

- ^2=  8.357 

Link 


EE 

peOqeD 

The  resulting  network  delay  constraints  are  now  more  restrictive  than  the  capacity 
constraints  and  must  be  substituted  for  the  capacity  constraints. 
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Solution!:  (Delay <. 05) 


Arc  1-3  (C-48):  XjXj 


Delay  .05 

yDelayii-C  13 


P,q<_ 


Link 


y-Delay  ia-C  ^3 
Link 


=  50.357 


peOqeD 


SS 

peOqeD 


50 


Arc  1-4  (C-40): 

peOqeD 

X„''  ’=39 

peOqeD 


y-Delay  ia  C  ^4  y  Delay  n*C  14 


=  39.643 


Link 


Link 


_ _ _ ,  yDelayM.C24 

Arc  2-4  (C=42):  XI  Xi  ^  " "  Lhi 

peOqeD 


EE 

peOqeD 


y  •  Delay- (Ji-C  24 
Link 


=  41.786 


This  solution  does  not  create  a  more  restrictive  delay  constraint  set  and  is  therefore  redun 
The  same  solution  set  that  was  used  in  Step  2.2  is  used. 
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Solution  3:  (Delay  <  .10) 


Delay  ;=  .10 


Arc  1-3  (C=48): 


peOqeD 


pq^Y-Delay^-Ci3 

Link 


SZXu''’=>00 

peOqeD 


y«Delay-p-C 

- if  =  100,714 

Link 


Arc  1-4  (C=40): 


V’V"  ^  p,q^yDelayn-Ci4 
- — — 

peOqeD 


X 


p,q- 


79 


peOqeD 


7-Delay-|a-C  14 

- —  =  79.286 

Link 


Arc  2-4  (C=42): 


yDelayn-C24 

2-1 2-i  “  Link 

peOqeD 


y*Delay-p-C24 

Link 


83.571 


EZ 

peOqeD 

This  solution  does  not  create  a  more  restrictive  delay  constraint  set  and  is  therefor 
redundant.  The  same  solution  set  that  was  used  in  Step  2.2  is  used. 
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D.  4  SAS/OR  Network  Locations  Code  (Delay  <  .  01) 


The  SAS/OR  code  is  the  same  for  solutions  associated  with  locations  (1  &  2)  and 
(3  &  2).  This  code  is  presented  next.  Since  the  delay  values  did  not  change  for  location 
(1  &  5),  that  code  is  not  presented. 

OPTIONS  LINESIZE=72; 

TITLE  '  COMMUNICATIONS  NETWORK  -  CASE  1 :  SOLUTION  2  '  ; 

TITLE2  'MULTI -COMMODITY  TELECOMMUNICATION  NETWORK'/ 

TITLE3  'DELAY  OBJECTIVE  FUNCTION  INCLUDED  AS  CONSTRAINT'; 

DATA  NODEO; 

INPUT  _NODE_  $  _SUPDEM_; 

CARDS; 

Nl_l  30 
N4_l  -30 
N2_2  30 
Nl_2  -30 
N3_3  30 
N5_3  -30 
N4_4  30 
N5_4  -30 
N5_5  30 
N2_5  -30 
/ 

DATA  ARCO; 

INPUT  TAIL_  $  _HEAD_  $  _COST _ CAPAC _ LO_  _NAME_$6  .  ; 


CARDS; 

Nl_l 

N3_l 

1 

10 

.  A131 

Nl__l 

N4_l 

1 

7 

.  A141 

Nl_l 

N5_l 

1 

7 

.  A151 

N3_l 

N4_l 

1 

7 

.  A341 

N3_l 

N2_l 

1 

7 

.  A321 

N2_l 

N3_l 

1 

7 

.  A231 

N5_l 

N2_l 

1 

8 

.  A521 

N2_l 

N4_l 

1 

8 

.  A241 

N2_2 

N3_2 

1 

7 

.  A232 

N2_2 

N4_2 

1 

8 

.  A242 

N2_2 

N5_2 

1 

8 

.  A252 

N3_2 

N4_2 

1 

7 

.  A342 

N3_2 

Nl_2 

1 

10 

.  A3 12 

N4_2 

N3_2 

1 

7 

.  A432 

N5_2 

Nl_2 

1 

7 

.  A512 

N4_2 

Nl_2 

1 

7 

.  A412 

N3_3 

Nl_3 

1 

10 

.  A3 13 

N3_3 

N2__3 

1 

7 

.  A323 

N3_3 

N4_3 

1 

7 

.  A343 

N4__3 

N2_3 

1 

8 

.  A423 

N4_3 

Nl_3 

1 

7 

.  A413 

Nl_3 

N5_3 

1 

7 

.  A153 

N2_3 

N5_3 

1 

8 

.  A253 

N4  4 

N1  4 

1 

7 

.  A414 
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N4_4  N2_4  1  8  .  A424 

N4_4  N3_4  1  7  .  A434 

N3_4  Nl_4  1  10  .  A3 14 
N3_4  N2_4  1  7  .  A3 24 

N2_4  N3_4  1  7  .  A234 

Nl_4  N3_4  1  10  .  A134 
N2_4  N5_4  1  8  .  A254 

Nl_4  N5_4  1  7  .  A154 

N5_5  Nl_5  1  7  .  A515 

N5_5  N2_5  1  8  .  A525 

Nl_5  N3_5  1  10  .  A135 
Nl_5  N4_5  1  7  .  A145 

N3_5  N2_5  1  7  .  A3 2 5 

N3_5  N4_5  1  7  .  A3 4 5 

N4_5  N2_5  1  8  .  A425 

N4_5  N3_5  1  7  .  A435 

Nl_l  N6_l  100  30  .  LCl 
N6_l  N4_l  1  30  .  D1 
N2_2  N6_2  100  30  .  LC2 
N6_2  Nl_2  1  30  .  D2 
N3_3  N6_3  100  30  .  LC3 
N6_3  N5_3  1  30  .  D3 
N4_4  N6_4  100  30  .  LC4 
N6_4  N5_4  1  30  .  D4 
N5_5  N6_5  100  30  .  LC5 
N6_5  N2_5  1  30  .  D5 
/ 

DATA  CONDO; 

INPUT  _COLUiyiN_  $  _R0W1  $  _C0EF1  ; 

CARDS; 

A131  CONI  1 
A141  CON5  1 
A151  CON2  1 
A3 41  CON6  1 
A3  21  CON4  1 
A231  CON4  1 
A521  CON3  1 
A241  CON7  1 
A232  CON4  1 
A242  CON7  1 
A252  CON3  1 
A3 4 2  CON6  1 
A3 12  CONI  1 
A432  CON6  1 
A512  CON2  1 
A412  CONS  1 
A3 13  CONI  1 
A3 2 3  CON4  1 
A3 4 3  CON6  1 
A423  CON7  1 
A413  CONS  1 
A1S3  CON2  1 


D41 


A253 

CON3 

1 

A414 

CON5 

1 

A424 

CON7 

1 

A434 

CON6 

1 

A3 14 

CONI 

1 

A324 

CON4 

1 

A234 

CON4 

1 

A134 

CONI 

1 

A254 

CON3 

1 

A154 

CON2 

1 

A515 

CON2 

1 

A525 

CON3 

1 

A135 

CONI 

1 

A145 

CONS 

1 

A325 

CON4 

1 

A345 

CON6 

1 

A425 

CON7 

1 

A435 

CON6 

1 

_TYPE_ 

CONI 

-1 

__TYPE_ 

CON2 

-1 

_TYPE_ 

CON3 

“1 

_TYPE_ 

CON4 

_TYPE^ 

CONS 

"1 

_TYPE_^ 

CON6 

-1 

_TYPE^ 

CON7 

-1 

_RHS_ 

CONI 

10 

_RHS_ 

CON2 

7 

__RHS_ 

CON3 

8 

__RHS_ 

CON4 

7 

_RHS_ 

CONS 

7 

_RHS_ 

CON6 

7 

RHS 

CON7 

8 

PROC  NETFLOW 
SCDATA 

NODEDATA=NODE  0 
ARCDATA=ARCO 
CONDATA=  CONDO 
CONOUT=SOLUTION ; 

RUN; 

PROC  PRINT  DATA=SOLUTION 
SUM  _FCOST_; 

SUM  _DEMAND_; 

RUN; 

ENDSAS ; 


D.5  SAS/OR  Network  Locations  Code  (Delay  <  .01)  Solution 


COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  2  1 

MULTI -COMMODITY  TELECOMMUNICATION  NETWORK 
DELAY  OBJECTIVE  FUNCTION  INCLUDED  AS  CONSTRAINT 

13:17  Sunday,  February  19,  1995 
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COMMUNICATIONS  NETWORK  -  CASE  1:  SOLUTION  2 
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Appendix  E.  Algorithm  Flowchart 
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